-
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
Set LLVM LLVM_UNREACHABLE_OPTIMIZE
to OFF
#109373
Conversation
r? @ozkanonur (rustbot has picked a reviewer for you, use r? to override) |
I thought about opening an issue for this, but might as well just be a PR since it only takes one line to change the option. Something Rust should consider at least. |
@bors r+ @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment was marked as resolved.
This comment was marked as resolved.
@bors r- |
oops, wrong command |
⌛ Trying commit a6c3e0c0283908ba2433e6e52882ac114a96f961 with merge 1dc0c6ee15d57fe1b7fda23cd4e4711a65b4d96f... |
Actually, I don't think our LLVM submodule has this new change yet, does it? |
It does have. |
☀️ Try build successful - checks-actions |
1 similar comment
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (1dc0c6ee15d57fe1b7fda23cd4e4711a65b4d96f): comparison URL. Overall result: no relevant changes - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bors r+
ops, bors can't get triggered from review note seems like @bors r+ |
📌 Commit a6c3e0c0283908ba2433e6e52882ac114a96f961 has been approved by It is now in the queue for this repository. |
perf was neutral and the queue is pretty filled up |
I forgot to do that, thanks |
@bors r- |
This option was added to LLVM in https://reviews.llvm.org/D121750?id=416339. It makes `llvm_unreachable` in builds without assertions compile to an `LLVM_BUILTIN_TRAP` instead of `LLVM_BUILTIN_UNREACHABLE` (which causes undefined behavior and is equivalent to `std::hint::unreachable_unchecked`). Having compiler bugs triggering undefined behavior generally seems undesirable and inconsistent with Rust's goals. There is a check in `src/tools/tidy/src/style.rs` to reject code using `llvm_unreachable`. But it is used a lot within LLVM itself. For instance, this changes a failure I get compiling `libcore` for m68k from a `SIGSEGV` to `SIGILL`, which seems better though it still doesn't provide a useful message without switching to an LLVM build with asserts. It may be best not to do this if it noticeably degrades compiler performance, but worthwhile if it doesn't do so in any significant way. I haven't looked into what benchmarks there are for Rustc. That should be considered before merging.
a6c3e0c
to
dfbf610
Compare
@bors r+ |
@bors rollup |
… r=ozkanonur Set LLVM `LLVM_UNREACHABLE_OPTIMIZE` to `OFF` This option was added to LLVM in https://reviews.llvm.org/D121750?id=416339. It makes `llvm_unreachable` in builds without assertions compile to an `LLVM_BUILTIN_TRAP` instead of `LLVM_BUILTIN_UNREACHABLE` (which causes undefined behavior and is equivalent to `std::hint::unreachable_unchecked`). Having compiler bugs triggering undefined behavior generally seems undesirable and inconsistent with Rust's goals. There is a check in `src/tools/tidy/src/style.rs` to reject code using `llvm_unreachable`. But it is used a lot within LLVM itself. For instance, this changes a failure I get compiling `libcore` for m68k from a `SIGSEGV` to `SIGILL`, which seems better though it still doesn't provide a useful message without switching to an LLVM build with asserts. It may be best not to do this if it noticeably degrades compiler performance, but worthwhile if it doesn't do so in any significant way. I haven't looked into what benchmarks there are for Rustc. That should be considered before merging.
… r=ozkanonur Set LLVM `LLVM_UNREACHABLE_OPTIMIZE` to `OFF` This option was added to LLVM in https://reviews.llvm.org/D121750?id=416339. It makes `llvm_unreachable` in builds without assertions compile to an `LLVM_BUILTIN_TRAP` instead of `LLVM_BUILTIN_UNREACHABLE` (which causes undefined behavior and is equivalent to `std::hint::unreachable_unchecked`). Having compiler bugs triggering undefined behavior generally seems undesirable and inconsistent with Rust's goals. There is a check in `src/tools/tidy/src/style.rs` to reject code using `llvm_unreachable`. But it is used a lot within LLVM itself. For instance, this changes a failure I get compiling `libcore` for m68k from a `SIGSEGV` to `SIGILL`, which seems better though it still doesn't provide a useful message without switching to an LLVM build with asserts. It may be best not to do this if it noticeably degrades compiler performance, but worthwhile if it doesn't do so in any significant way. I haven't looked into what benchmarks there are for Rustc. That should be considered before merging.
…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#109373 (Set LLVM `LLVM_UNREACHABLE_OPTIMIZE` to `OFF`) - rust-lang#109392 (Custom MIR: Allow optional RET type annotation) - rust-lang#109394 (adapt tests/codegen/vec-shrink-panik for LLVM 17) - rust-lang#109412 (rustdoc: Add GUI test for "Auto-hide item contents for large items" setting) - rust-lang#109452 (Ignore the vendor directory for tidy tests.) - rust-lang#109457 (Remove comment about reusing rib allocations) - rust-lang#109461 (rustdoc: remove redundant `.content` prefix from span/a colors) - rust-lang#109477 (`HirId` to `LocalDefId` cleanup) - rust-lang#109489 (More general captures) - rust-lang#109494 (Do not feed param_env for RPITITs impl side) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
This option was added to LLVM in https://reviews.llvm.org/D121750?id=416339. It makes
llvm_unreachable
in builds without assertions compile to anLLVM_BUILTIN_TRAP
instead ofLLVM_BUILTIN_UNREACHABLE
(which causes undefined behavior and is equivalent tostd::hint::unreachable_unchecked
).Having compiler bugs triggering undefined behavior generally seems undesirable and inconsistent with Rust's goals. There is a check in
src/tools/tidy/src/style.rs
to reject code usingllvm_unreachable
. But it is used a lot within LLVM itself.For instance, this changes a failure I get compiling
libcore
for m68k from aSIGSEGV
toSIGILL
, which seems better though it still doesn't provide a useful message without switching to an LLVM build with asserts.It may be best not to do this if it noticeably degrades compiler performance, but worthwhile if it doesn't do so in any significant way. I haven't looked into what benchmarks there are for Rustc. That should be considered before merging.