-
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
Unconditionally emit the target-cpu LLVM attribute. #56609
Unconditionally emit the target-cpu LLVM attribute. #56609
Conversation
@bors try |
⌛ Trying commit 86822eb with merge 85f3e04b446e18c8043659f95d0118320dc135af... |
r=me assuming perf looks reasonable |
☀️ Test successful - status-travis |
@rust-timer build 85f3e04b446e18c8043659f95d0118320dc135af |
Success: Queued 85f3e04b446e18c8043659f95d0118320dc135af with parent 1c3236a, comparison URL. |
That does not appear to be true at all? That is, I don’t recall seeing this attribute in code generated by rustc, ever. There is one use case of mine that is semi-broken by unconditionally emitting target-cpu attribute. When investigating codegen bugs for trivial code, I like emiting LLVM-IR and running it through
a dozen times for each function, making it necessary to remove those attributes somehow to make it workable. Not that I’m gonna block this PR on it, it is just something I felt was not taken into account of being possible :) |
What I meant was: When compiling all of your code with xLTO then only the libstd LLVM IR pulled in from crate metadata would not have the attribute. I'm sorry about the regression you mention |
Finished benchmarking try commit 85f3e04b446e18c8043659f95d0118320dc135af |
The performance difference looks like noise. @bors r=alexcrichton |
📌 Commit 86822eb has been approved by |
…et-cpu-attr, r=alexcrichton Unconditionally emit the target-cpu LLVM attribute. This PR makes `rustc` always emit the `target-cpu` LLVM attribute for functions. The goal is to allow for cross-language inlining of functions defined in `libstd`. So far `libstd` functions were the only function without a `target-cpu` attribute, so in whole-crate-graph cross-lang LTO scenarios they were not eligible for inlining into foreign code. r? @alexcrichton
⌛ Testing commit 86822eb with merge 91e470ccc038fc9010f49872b1869d5bde2ad819... |
💔 Test failed - status-appveyor |
@bors: retry |
…et-cpu-attr, r=alexcrichton Unconditionally emit the target-cpu LLVM attribute. This PR makes `rustc` always emit the `target-cpu` LLVM attribute for functions. The goal is to allow for cross-language inlining of functions defined in `libstd`. So far `libstd` functions were the only function without a `target-cpu` attribute, so in whole-crate-graph cross-lang LTO scenarios they were not eligible for inlining into foreign code. r? @alexcrichton
…et-cpu-attr, r=alexcrichton Unconditionally emit the target-cpu LLVM attribute. This PR makes `rustc` always emit the `target-cpu` LLVM attribute for functions. The goal is to allow for cross-language inlining of functions defined in `libstd`. So far `libstd` functions were the only function without a `target-cpu` attribute, so in whole-crate-graph cross-lang LTO scenarios they were not eligible for inlining into foreign code. r? @alexcrichton
…et-cpu-attr, r=alexcrichton Unconditionally emit the target-cpu LLVM attribute. This PR makes `rustc` always emit the `target-cpu` LLVM attribute for functions. The goal is to allow for cross-language inlining of functions defined in `libstd`. So far `libstd` functions were the only function without a `target-cpu` attribute, so in whole-crate-graph cross-lang LTO scenarios they were not eligible for inlining into foreign code. r? @alexcrichton
…et-cpu-attr, r=alexcrichton Unconditionally emit the target-cpu LLVM attribute. This PR makes `rustc` always emit the `target-cpu` LLVM attribute for functions. The goal is to allow for cross-language inlining of functions defined in `libstd`. So far `libstd` functions were the only function without a `target-cpu` attribute, so in whole-crate-graph cross-lang LTO scenarios they were not eligible for inlining into foreign code. r? @alexcrichton
Rollup of 14 pull requests (first batch) Successful merges: - #56562 (Update libc version required by rustc) - #56609 (Unconditionally emit the target-cpu LLVM attribute.) - #56637 (rustdoc: Fix local reexports of proc macros) - #56658 (Add non-panicking `maybe_new_parser_from_file` variant) - #56695 (Fix irrefutable matches on integer ranges) - #56699 (Use a `newtype_index!` within `Symbol`.) - #56702 ([self-profiler] Add column for percent of total time) - #56708 (Remove some unnecessary feature gates) - #56709 (Remove unneeded extra chars to reduce search-index size) - #56744 (specialize: remove Boxes used by Children::insert) - #56748 (Update panic message to be clearer about env-vars) - #56749 (x86: Add the `adx` target feature to whitelist) - #56756 (Disable btree pretty-printers on older gdbs) - #56789 (rustc: Add an unstable `simd_select_bitmask` intrinsic) r? @ghost
This PR makes
rustc
always emit thetarget-cpu
LLVM attribute for functions. The goal is to allow for cross-language inlining of functions defined inlibstd
. So farlibstd
functions were the only function without atarget-cpu
attribute, so in whole-crate-graph cross-lang LTO scenarios they were not eligible for inlining into foreign code.r? @alexcrichton