Adjust -Ctarget-cpu=native handling in cg_llvm

[nagisa]

When cg_llvm encounters the -Ctarget-cpu=native it computes an
explciit set of features that applies to the target in order to
correctly compile code for the host CPU (because e.g. skylake alone is
not 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 that
are implicitly set by the target definition. However due to how other
-Ctarget-cpu values are handled we must adopt the following order
of priority:

• Features from -Ctarget-cpu=*; are overriden by
• Features implied by --target; are overriden by
• Features from -Ctarget-feature; are overriden by
• function specific features.

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 function
without #[target_feature(enable)] annotation would have a broader
set 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 in
particular on developer or CI machines.

cc #83027 @BurntSushi

[rust-highfive]

r? @petrochenkov

(rust-highfive has picked a reviewer for you, use r? to override)

[BurntSushi]

Thank you @nagisa!!!

[lqd]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit 1e8f7dbfcd15e5154f84e00c1e4c9603f14752e3 with merge dda2654d0b2e9f8d11f6c86075e2a08bd80867d9...

[bors]

☀️ Try build successful - checks-actions
Build commit: dda2654d0b2e9f8d11f6c86075e2a08bd80867d9 (dda2654d0b2e9f8d11f6c86075e2a08bd80867d9)

[rust-timer]

Queued dda2654d0b2e9f8d11f6c86075e2a08bd80867d9 with parent 2caeeb0, future comparison URL.

[rust-timer]

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 rollup- to bors.

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
@rustbot label: +S-waiting-on-review -S-waiting-on-perf

[petrochenkov]

PR description needs to be updated.
r=me after that.

[nagisa]

@bors r=petrochenkov

(was missing a --target in one of the tests)

[bors]

📌 Commit 72fb437 has been approved by petrochenkov

[bors]

⌛ Testing commit 72fb437 with merge 0c34122...

[bors]

☀️ Test successful - checks-actions
Approved by: petrochenkov
Pushing 0c34122 to master...

[camelid]

Does this fix #83027?

[camelid]

If so, this PR should probably be backported to beta so the bug isn't in 1.51.

[nagisa]

I didn't test the original reproducer, remains for the others to verify.

[pnkfelix]

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:

this problem only affects a small number of people using a very specific flag combination which isn't a default and has been known to break in other ways in the past (miscompile)

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.

[BurntSushi]

@pnkfelix I agree with not back-porting. If this didn't require target-cpu=native to be triggered, that'd be a different story. But target-cpu=native definitely makes this lower impact!

[pnkfelix]

(hmm can someone tell me why rustbot removed the beta-nomination up above? Was that because of #83027 getting closed somehow...?)

[apiraino]

(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 @rustbot label -beta-nominated 7 minutes after you wrote yours but my page didn't refresh so I wasnt aware of it. I have then removed my comment and manually reinstated the beta-nominated label. Which you then removed again 😄