Repository navigation
Target features getting erased when using #[export_name] with names of LLVM intrinsics #140822
Description
TIL Rust "supports" #[export_name] with names of LLVM intrinsics! The following code compiles no problem
#[unsafe(export_name = "llvm.x86.rdtsc")]
fn foo() {
// ...
}(FYI llvm.x86.rdtsc is a very real LLVM intrinsic, used to read the timestamp counter value in x86)
which imo should be hard error anyway. But then if we combine this monstrosity with #[target_feature] (or -C target-feature for that matter), all the target feature data for that function is erased. This is possible even in stable Rust, both in debug and release profile.
Godbolt link https://godbolt.org/z/h7jdrsY54
Meta
Doing a naive bisect on Godbolt, I found out that this bug was introduced in 1.29.0!!
https://godbolt.org/z/8M9a4vs9Y
The solution is probably just disallow any #[export_name]'s that try to masquerade as LLVM intrinsics (i.e. name starts with llvm.), which will mean reverting to pre-1.29.0 behavior.
@rustbot label T-compiler
Activity
moxian commentedon May 8, 2025
The example on godbolt has been producing llvm IR, but refused to codegen between
1.29.0and1.84.0. Specifically, up until #133499 . So arguably there has been no "real bug" in that period.The earlier change in
1.28.0->1.29.0(error -> no error in--emit=llvm-ir) points to either #51230 or (less likely) #51966(full list of PRs in nightly-2018-07-13)
so this was never been a rustc native behaviour, and we've always relied on LLVM to catch this (until recently).
cc @nikic
I'm not quite sure how
#[target_feature]is relevant here. The only thing it is seemingly doing in the godbolt example is specifying"target-features"="in the attributes list (which is expected), but nothing else. Unless I'm badly misreading this https://godbolt.org/z/83M6noTG7@rustbot label: +A-llvm
sayantn commentedon May 8, 2025
If you look closely, you can see that the function exported with the existing llvm intrinsic name has different target features than the other ones (in your example, the
llvm.x86.rdtscone has#0, which doesn't have any target features, whereas the other 2 has#1, which has target featureavx).Without the target feature thing, this isn't formally a "bug", just surprising (but predictable) behavior. When the target features get erased, it will start to throw rustc-LLVM errors because the inside block uses
avxthings, but now apparentlyavxis not available anymore (which is whattarget_featureprotects us against)nikic commentedon May 8, 2025
Creating a definition for an intrinsic is invalid LLVM IR, the rest is not really relevant. The Rust frontend must generate an error when trying to use an export_name starting with
llvm..