compiler-builtins: plumb LSE support for aarch64 on linux/gnu when optimized-compiler-builtins not enabled

[pmur]

Add dynamic support for aarch64 LSE atomic ops on linux/gnu targets when optimized-compiler-builtins is not enabled.

Enabling LSE is the primary motivator for #143689, though extending the rust version doesn't seem too farfetched. Are there more details which I have overlooked which make this impractical? I've tested this on an aarch64 host with LSE.

r? @tgross35

[tgross35]

Agreed that we should be able to support these in compiler-builtins. I think one problem with the current implementation is linker errors for no_std binaries on the aarch64-unknown-linux-gnu target if getauxval isn't supplied somewhere (whether or not we want to support this usecase is still up for debate).

Would things work if the check+init routine was moved into std::sys rather than within builtins? This should avoid any no-std concerns, and is_aarch64_feature_detected could be used rather than directly calling getauxval.

I'm certain @Amanieu has some thoughts here

[pmur]

Would things work if the check+init routine was moved into std::sys rather than within builtins? This should avoid any no-std concerns, and is_aarch64_feature_detected could be used rather than directly calling getauxval.

Hrm, the check does need to move out. Where in std::sys would the check belong?

Technically, I don't think the switchover to LSE has to happen very early, but earlier is probably better for performance.

[pmur]

Looking closer, if optimized-compiler-builtins are enabled and no-std is used, the user must supply a getauxval if they use the compiler-builtins on a gnu target (at least with the recent stable compiler I tried).

How much trouble would it be to explicitly require a user to supply getauxval in these cases?

[tgross35]

Hrm, the check does need to move out. Where in std::sys would the check belong?

There probably isn't a good fit currently. Maybe a new module like configure_builtins.rs?

Technically, I don't think the switchover to LSE has to happen very early, but earlier is probably better for performance.

Would the library where the configuration code lives make a difference for timing? I think init_array could still be used, we have another instance at

rust/library/std/src/sys/args/unix.rs

Line 120 in 3fb1b53

#[unsafe(link_section = ".init_array.00099")]

.

Looking closer, if optimized-compiler-builtins are enabled and no-std is used, the user must supply a getauxval if they use the compiler-builtins on a gnu target (at least with the recent stable compiler I tried).

How much trouble would it be to explicitly require a user to supply getauxval in these cases?

Good point, that part probably doesn't actually matter then.

It is likely still beneficial to keep compiler-rt code that needs the C standard library in std if possible, I assume compiler-rt just has everything together because it doesn't have any control over libc. Not as relevant for the one libcall here (compared to e.g. #138944), but one advantage is that we're calling getauxval anyway, may as well benefit from initializing std's is_aarch64_feature_detected cache.

[tgross35]

It's probably okay to call this directly in std, but all builtins intrinsics are called by extern so it's probably safest to do the same here (the std dependency should actually be removed in 42bf044). The intrinsics macro handles no_mangle and weak linkage:

intrinsics! {
    pub extern "C" fn __rust_enable_lse() {
        // ...
    }
}

Any reason this is a draft still? Assuming you have tested that the current setup works, it lgtm with the above change (though I'll ask Amaieu to take a look)

[tgross35]

Looks like we actually do have this on musl since very recently 3d0dedd. Gating on target_feature = "outline-atomics" would be ideal, but that doesn't seem to work for some reason.

[tgross35]

Gating on target_feature = "outline-atomics" would be ideal, but that doesn't seem to work for some reason.

#144761

[Amanieu]

At the moment this is the only way I can see this working. Fundamentally compiler-builtins is not able to call into other libraries so LSE must be manually initialized from outside.