Skip to content
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

Merged
merged 1 commit into from
Mar 23, 2023

Conversation

ids1024
Copy link
Contributor

@ids1024 ids1024 commented Mar 20, 2023

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.

@rustbot
Copy link
Collaborator

rustbot commented Mar 20, 2023

r? @ozkanonur

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) labels Mar 20, 2023
@ids1024
Copy link
Contributor Author

ids1024 commented Mar 20, 2023

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.

@Noratrieb
Copy link
Member

@bors r+ @rust-timer queue

@rust-timer

This comment has been minimized.

@bors

This comment was marked as resolved.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 20, 2023
@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Mar 20, 2023
@Noratrieb
Copy link
Member

@bors r-

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 20, 2023
@Noratrieb
Copy link
Member

oops, wrong command
@bors try

@bors
Copy link
Contributor

bors commented Mar 20, 2023

⌛ Trying commit a6c3e0c0283908ba2433e6e52882ac114a96f961 with merge 1dc0c6ee15d57fe1b7fda23cd4e4711a65b4d96f...

@Noratrieb
Copy link
Member

Actually, I don't think our LLVM submodule has this new change yet, does it?

@onur-ozkan
Copy link
Member

onur-ozkan commented Mar 20, 2023

Actually, I don't think our LLVM submodule has this new change yet, does it?

It does have.

rust-lang/llvm-project@7b98391

@bors
Copy link
Contributor

bors commented Mar 20, 2023

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

1 similar comment
@bors
Copy link
Contributor

bors commented Mar 20, 2023

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

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (1dc0c6ee15d57fe1b7fda23cd4e4711a65b4d96f): comparison URL.

Overall result: no relevant changes - no action needed

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

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This 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.

mean range count
Regressions ❌
(primary)
1.7% [0.6%, 2.8%] 2
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.9% [-1.2%, -0.5%] 3
Improvements ✅
(secondary)
-3.4% [-4.7%, -2.1%] 2
All ❌✅ (primary) 0.1% [-1.2%, 2.8%] 5

Cycles

Results

This 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.

mean range count
Regressions ❌
(primary)
0.5% [0.5%, 0.5%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.6% [-0.6%, -0.6%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -0.0% [-0.6%, 0.5%] 2

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Mar 20, 2023
Copy link
Member

@onur-ozkan onur-ozkan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bors r+

@onur-ozkan
Copy link
Member

ops, bors can't get triggered from review note seems like

@bors r+

@bors
Copy link
Contributor

bors commented Mar 21, 2023

📌 Commit a6c3e0c0283908ba2433e6e52882ac114a96f961 has been approved by ozkanonur

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 21, 2023
@Noratrieb
Copy link
Member

perf was neutral and the queue is pretty filled up
@bors rollup=maybe
feel free to set it to rollup=never again if we prefer to not roll up changes like this (I'm not sure on that)

@onur-ozkan
Copy link
Member

feel free to set it to rollup=never again if we prefer to not roll up changes like this (I'm not sure on that)

I forgot to do that, thanks

@onur-ozkan
Copy link
Member

@bors r-

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 21, 2023
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.
@onur-ozkan
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Mar 21, 2023

📌 Commit dfbf610 has been approved by ozkanonur

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 21, 2023
@onur-ozkan
Copy link
Member

@bors rollup

Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Mar 21, 2023
… 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.
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Mar 22, 2023
… 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.
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 22, 2023
…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
@bors bors merged commit 56959e5 into rust-lang:master Mar 23, 2023
@rustbot rustbot added this to the 1.70.0 milestone Mar 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants