codegen #[naked] functions using global asm

[folkertdev]

tracking issue: #90957

Fixes #124375

This implements the approach suggested in the tracking issue: use the existing global assembly infrastructure to emit the body of #[naked] functions. The main advantage is that we now have full control over what gets generated, and are no longer dependent on LLVM not sneakily messing with our output (inlining, adding extra instructions, etc).

I discussed this approach with @Amanieu and while I think the general direction is correct, there is probably a bunch of stuff that needs to change or move around here. I'll leave some inline comments on things that I'm not sure about.

Combined with #127853, if both accepted, I think that resolves all steps from the tracking issue.

r? @Amanieu

[tgross35]

On the tracking issue a naked_asm! macro was proposed that would closer follow global_asm! (cc @Lokathor since you liked this idea). It sounds like this PR effectively turns #[naked] + asm! into exactly what naked_asm would do, so that would no longer be necessary?

The changes in this PR seem like good direction.

[Lokathor]

I think that separately from any internal implementation change, the surface syntax of rust should use naked_asm separately from asm, because the two have different enough user interface and semantics.

[folkertdev]

I agree that it is still a good idea to add naked_asm! as a public api, if only because it makes the documentation much more straightforward: instead of having to explain the interaction between #[naked] and asm!, we just mandate that #[naked] must use a naked_asm! block and the naked_asm! docs can give the exact details and restrictions.

But that is separate from how the codegen works, which is what this PR is for.

[folkertdev]

I've not been able to actually generate code that triggers this if. Visibility just seems to always be Default. So this is entirely untested at the moment.

[tgross35]

For anything like this, drop a question on Zulip https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp. Unfortunately that enum doesn't seem to be very well documented

[bjorn3]

This function can probably just take TyCtxt.

[bjorn3]

Ah, this layout_of call uses the CodegenCx. This is during codegen though, so RevealAllLayoutCx (a wrapper around TyCtxt) is enough: https://github.com/rust-lang/rustc_codegen_cranelift/blob/b70ad2defd4bb5fba6af7958893e22be0f33dfdd/src/common.rs#L450-L518 Maybe it should be uplifted out of cg_clif?

[folkertdev]

seems useful, should that be part of this PR though?

[bors]

☔ The latest upstream changes (presumably #128298) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #125443) made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

[folkertdev]

I think this is as far as I can take it without some external feedback

@rustbot ready

[Amanieu]

Overall LGTM. I'm still not 100% sure about the linkage-related things, but I think it's good enough to merge. We can handle any issues that are discovered later.

[Amanieu]

Also test that at the end of each function the assember mode is restored to the default for the target.

[folkertdev]

what are these assembler modes based on? I don't see .arm here at all, and for thumb only thumb_function appears to be used.

https://godbolt.org/z/rjjc4KxnG

and even then only at the start, not at the end

        .section        .text.test_thumb,"ax",%progbits
        .globl  test_thumb
        .p2align        1
        .type   test_thumb,%function
        .code   16
        .thumb_func
test_thumb:
.Lfunc_begin0:
        .fnstart
        .cfi_sections .debug_frame
        .cfi_startproc
        .file   1 "/app" "example.rs"
        .loc    1 19 5 prologue_end
        bx      lr
        .inst.n 0xdefe
.Lfunc_end0:
        .size   test_thumb, .Lfunc_end0-test_thumb
        .cfi_endproc
        .cantunwind
        .fnend

[folkertdev]

this is confusing, the assert is triggered in this example

    let is_thumb = tcx.sess.unstable_target_features.contains(&sym::thumb_mode);

    let attrs = tcx.codegen_fn_attrs(instance.def_id());
    let link_section = attrs.link_section.map(|symbol| symbol.as_str().to_string());
    let align = attrs.alignment.map(|a| a.bytes()).unwrap_or(4);

    let (arch_prefix, arch_suffix) = if is_arm {
        (
            match attrs.instruction_set {
                None => match is_thumb {
                    true => ".thumb\n.thumb_func",
                    false => ".arm",
                },
                Some(InstructionSetAttr::ArmT32) => {
                    assert!(is_thumb);
                    ".thumb\n.thumb_func"
                }

that conflicts with

/// Computes the set of target features used in a function for the purposes of
/// inline assembly.
fn asm_target_features(tcx: TyCtxt<'_>, did: DefId) -> &FxIndexSet<Symbol> {
    let mut target_features = tcx.sess.unstable_target_features.clone();
    if tcx.def_kind(did).has_codegen_attrs() {
        let attrs = tcx.codegen_fn_attrs(did);
        target_features.extend(attrs.target_features.iter().map(|feature| feature.name));
        match attrs.instruction_set {
            None => {}
            Some(InstructionSetAttr::ArmA32) => {
                // FIXME(#120456) - is `swap_remove` correct?
                target_features.swap_remove(&sym::thumb_mode);
            }
            Some(InstructionSetAttr::ArmT32) => {
                target_features.insert(sym::thumb_mode);
            }
        }
    }

    tcx.arena.alloc(target_features)
}

so information is getting lost somewhere I think?

[bors]

☔ The latest upstream changes (presumably #130066) made this pull request unmergeable. Please resolve the merge conflicts.