-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adjust -Ctarget-cpu=native
handling in cg_llvm
#83084
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
f48521f
to
a5dbd0e
Compare
This comment has been minimized.
This comment has been minimized.
be2beea
to
1e8f7db
Compare
Thank you @nagisa!!! |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 1e8f7dbfcd15e5154f84e00c1e4c9603f14752e3 with merge dda2654d0b2e9f8d11f6c86075e2a08bd80867d9... |
☀️ Try build successful - checks-actions |
Queued dda2654d0b2e9f8d11f6c86075e2a08bd80867d9 with parent 2caeeb0, future comparison URL. |
Finished benchmarking try commit (dda2654d0b2e9f8d11f6c86075e2a08bd80867d9): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
1e8f7db
to
c5f6d90
Compare
c5f6d90
to
e156d48
Compare
This comment has been minimized.
This comment has been minimized.
e156d48
to
815bb8b
Compare
PR description needs to be updated. |
a80ba10
to
72fb437
Compare
@bors r=petrochenkov (was missing a |
📌 Commit 72fb437 has been approved by |
☀️ Test successful - checks-actions |
Does this fix #83027? |
If so, this PR should probably be backported to beta so the bug isn't in 1.51. |
I didn't test the original reproducer, remains for the others to verify. |
did a quick beta nomination and attempted to discuss at T-compiler meeting today, but the meeting was over time at that point so we didn't get much discussion. collectively I'd say we are hesitant at best to beta-backport this change. As nagisa put it in the meeting:
I'm leaving the beta-nomination label on it at the moment while we wait for @BurntSushi to respond about whether PR #83084 fixes #83027. But even if it does fix issue #83027, it seems likely that we'll still decline to backport; its a big patch and somewhat risky, which is a tough tradeoff given context established by nagisa above. |
@pnkfelix I agree with not back-porting. If this didn't require |
(hmm can someone tell me why rustbot removed the beta-nomination up above? Was that because of #83027 getting closed somehow...?) |
@pnkfelix heh ... github web UI sometimes fails to update comments. I had wrote a comment to |
…ouxu extend comment in global_llvm_features regarding target-cpu=native Based on the description in rust-lang#83084 by `@nagisa` -- seems better to have this in the code, where it is easier to find.
Rollup merge of rust-lang#131010 - RalfJung:target-cpu-native, r=jieyouxu extend comment in global_llvm_features regarding target-cpu=native Based on the description in rust-lang#83084 by `@nagisa` -- seems better to have this in the code, where it is easier to find.
When cg_llvm encounters the
-Ctarget-cpu=native
it computes anexplciit set of features that applies to the target in order to
correctly compile code for the host CPU (because e.g.
skylake
alone isnot sufficient to tell if some of the instructions are available or
not).
However there were a couple of issues with how we did this. Firstly, the
order in which features were overriden wasn't quite right – conceptually
you'd expect
-Ctarget-cpu=native
option to override the features thatare implicitly set by the target definition. However due to how other
-Ctarget-cpu
values are handled we must adopt the following orderof priority:
Another problem was in that the function level
target-features
attribute would overwrite the entire set of the globally enabled
features, rather than just the features the
#[target_feature(enable/disable)]
specified. With something like-Ctarget-cpu=native
we'd end up in a situation wherein a functionwithout
#[target_feature(enable)]
annotation would have a broaderset of features compared to a function with one such attribute. This
turned out to be a cause of heavy run-time regressions in some code
using these function-level attributes in conjunction with
-Ctarget-cpu=native
, for example.With this PR rustc is more careful about specifying the entire set of
features for functions that use
#[target_feature(enable/disable)]
or#[instruction_set]
attributes.Sadly testing the original reproducer for this behaviour is quite
impossible – we cannot rely on
-Ctarget-cpu=native
to be anything inparticular on developer or CI machines.
cc #83027 @BurntSushi