Add llvm.sideeffect to potential infinite loops and recursions #59546

sfanxiang · 2019-03-30T02:27:58Z

LLVM assumes that a thread will eventually cause side effect. This is
not true in Rust if a loop or recursion does nothing in its body,
causing undefined behavior even in common cases like loop {}.
Inserting llvm.sideeffect fixes the undefined behavior.

As a micro-optimization, only insert llvm.sideeffect when jumping back
in blocks or calling a function.

A patch for LLVM is expected to allow empty non-terminate code by
default and fix this issue from LLVM side.

#28728

UPDATE: Mentoring instructions here to unstall this PR

rust-highfive · 2019-03-30T02:28:08Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @michaelwoerister (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

src/test/run-pass/non-terminate/infinite-loop.rs

src/test/run-pass/non-terminate/infinite-recursion.rs

nagisa

Thanks for the PR!

The outcome here is about exactly what I had expected when to me it occurred that llvm.sideeffect is not a great workaround. I do not see any particularly strong issues with the implementation itself, so r=me on that.

The question is whether we are fine with regressing (at times seriously) the code quality for just about everything else in exchange for solving our most notable longstanding codegen issue, @rust-lang/compiler?

nagisa · 2019-03-30T11:31:51Z

src/test/codegen/issue-34947-pow-i32.rs

@@ -6,8 +6,8 @@
 #[no_mangle]
 pub fn issue_34947(x: i32) -> i32 {
    // CHECK: mul
-    // CHECK-NEXT: mul
-    // CHECK-NEXT: mul
-    // CHECK-NEXT: ret


This is a regression test to ensure that pow(<constant>) would unroll the loop properly. This change regresses that and the test adjusted to ignore its original intent.

I don't think pow(<constant>) regresses in this case. The codegen simply inserts a bunch of @llvm.sideeffect in between mul so we can't do CHECK-NEXT. The resulting code should be no different.

Can we then CHECK-NOT for branches between the multiply instructions?

nagisa · 2019-03-30T11:34:37Z

src/test/codegen/repeat-trusted-len.rs

@@ -14,6 +14,6 @@ pub fn helper(_: usize) {
 // CHECK-LABEL: @repeat_take_collect
 #[no_mangle]
 pub fn repeat_take_collect() -> Vec<u8> {
-// CHECK: call void @llvm.memset.p0i8.[[USIZE]](i8* {{(nonnull )?}}align 1 %{{[0-9]+}}, i8 42, [[USIZE]] 100000, i1 false)


Is this regressing and now the buffer size given to the intrinsic is not constant anymore?

Not exactly. IDK why but we get a single store and then memset with size = 99999 here.

Fair, can the test check for this specific pattern please? With {{.*}} it is possible to regress to, say, 100000 memsets all with 1 byte size without noticing.

nagisa · 2019-03-30T11:36:13Z

src/test/codegen/issue-45222.rs

@@ -1,3 +1,5 @@
+// ignore-test LLVM can't prove that these loops terminate.


This is a regression as well, right? Not great that even trivial examples like these regress...

src/test/run-pass/non-terminate/infinite-loop.rs

src/test/run-pass/non-terminate/infinite-recursion.rs

nagisa · 2019-03-30T11:43:23Z

@bors try

Lets do a perf run.

bors · 2019-03-30T11:44:08Z

⌛ Trying commit b3848cec68718b9a6382ca35816e2f36ce0394b6 with merge 2d35e031eb67c3fa339df66bc3e24e844faa09e5...

bors · 2019-03-30T14:11:00Z

☀️ Try build successful - checks-travis
Build commit: 2d35e031eb67c3fa339df66bc3e24e844faa09e5

nagisa · 2019-03-30T21:50:37Z

@rust-timer build 2d35e031eb67c3fa339df66bc3e24e844faa09e5

rust-timer · 2019-03-30T21:50:38Z

Success: Queued 2d35e031eb67c3fa339df66bc3e24e844faa09e5 with parent 709b72e, comparison URL.

rust-timer · 2019-03-31T02:38:22Z

Finished benchmarking try commit 2d35e031eb67c3fa339df66bc3e24e844faa09e5

sfanxiang · 2019-03-31T16:24:06Z

@nagisa Looking closer at perf, some benchmarks (e.g. keccak) spend quite some time in is_predecessor_of. So I replaced it with a simpler comparison of block index, assuming mir always generates in sequential order. If the assumption is false, the codegen would still be correct but the generated code would be less performant.

nagisa · 2019-03-31T21:08:11Z

Alas, the blocks are not required to be seuential by the time codegen happens.

If the assumption is false, the codegen would still be correct but the generated code would be less performant.

I’m not sure I see how: if we have start -> bb10 (loop head) -> bb1 (loop body) -> bb10 then the sideeffect would not get generated at all, would it?

sfanxiang · 2019-04-01T00:35:21Z

@nagisa
By sequential I mean, as long as there isn't a loop, the blocks should always execute in strictly increasing index (bb1 -> bb2, etc.) order. And we generate @llvm.sideeffect when we see equal or decreasing target index (e.g. bb2 -> bb1).

Let's suppose @llvm.sideeffect is not generated, which means all branches go to a strictly increasing index. Because the index is strictly increasing it's impossible to go back to a visited block, therefore can't form a loop. In other words, if @llvm.sideeffect isn't generated, there's no loop, regardless of the sequential assumption.

Now what if the assumption is false? That means the index goes back where there isn't a loop. In that case, an extra @llvm.sideeffect will be generated even when it's not needed, which hurts performance but not correctness. If the assumption is false, and if there's no loop, @llvm.sideeffect may still be generated.

And if the assumption is true, @llvm.sideeffect will be generated when and only when loop exists. These are only for blocks though. Functions always get a sideeffect.

Alas, the blocks are not required to be seuential by the time codegen happens.

I realize it's not required, but I couldn't find where rustc doesn't follow this assumption. Could you give me an example code where sequential code isn't generated sequentially when converted to mir?

I’m not sure I see how: if we have start -> bb10 (loop head) -> bb1 (loop body) -> bb10 then the sideeffect would not get generated at all, would it?

It will be generated in bb10 before branching to bb1.

nagisa · 2019-04-01T02:17:48Z

I see. Well, I guess we do another perf run to see how it fares this time around and perhaps it would be good to collect some benchmarks as well, although I’m not sure of what. Then we can just wait for the decision from the team meeting.

@bors try

bors · 2019-04-01T02:18:01Z

⌛ Trying commit 0ea0e06 with merge ef94533...

Add llvm.sideeffect to potential infinite loops and recursions LLVM assumes that a thread will eventually cause side effect. This is not true in Rust if a loop or recursion does nothing in its body, causing undefined behavior even in common cases like `loop {}`. Inserting llvm.sideeffect fixes the undefined behavior. As a micro-optimization, only insert llvm.sideeffect when jumping back in blocks or calling a function. A patch for LLVM is expected to allow empty non-terminate code by default and fix this issue from LLVM side. #28728

bors · 2019-04-01T04:38:58Z

☀️ Try build successful - checks-travis
Build commit: ef94533

oli-obk · 2019-04-01T08:58:43Z

@rust-timer build ef94533

nagisa · 2019-09-27T03:03:28Z

@Ekleog Don’t think so. Wouldn’t be great to have a work-around just for a temporary hack.

@nikic should we report to LLVM with our perf findings? I’m not entirely sure what the status of the “forward progress guarantees” discussion is at this point, last I remember there was some confusion around the direction in one of the differentials and then complete silence since.

nikomatsakis · 2019-09-27T14:25:51Z

Discussed in today's design meeting (login-free link). We opted not to schedule this but instead:

to merge the PR with a -Z flag
and to get some measurements from real-world applications
- @michaelwoerister will measure impact on FF
- @nikomatsakis will find someone to measure impact on some async-related applications

@sfanxiang would you be up for modifying this PR to make it so that the llvm.sideeffect instructions are gated on a -Z flag?

sfanxiang · 2019-09-27T19:49:31Z

@nikomatsakis

would you be up for modifying this PR to make it so that the llvm.sideeffect instructions are gated on a -Z flag?

Of course!

LLVM assumes that a thread will eventually cause side effect. This is not true in Rust if a loop or recursion does nothing in its body, causing undefined behavior even in common cases like `loop {}`. Inserting llvm.sideeffect fixes the undefined behavior. As a micro-optimization, only insert llvm.sideeffect when jumping back in blocks or calling a function. A patch for LLVM is expected to allow empty non-terminate code by default and fix this issue from LLVM side. rust-lang#28728

rust-highfive · 2019-09-27T21:21:07Z

The job mingw-check of your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

2019-09-27T20:52:08.8246863Z ##[command]git remote add origin https://github.com/rust-lang/rust
2019-09-27T20:52:08.8500384Z ##[command]git config gc.auto 0
2019-09-27T20:52:08.8575068Z ##[command]git config --get-all http.https://github.com/rust-lang/rust.extraheader
2019-09-27T20:52:08.8633381Z ##[command]git config --get-all http.proxy
2019-09-27T20:52:08.8793219Z ##[command]git -c http.extraheader="AUTHORIZATION: basic ***" fetch --force --tags --prune --progress --no-recurse-submodules --depth=2 origin +refs/heads/*:refs/remotes/origin/* +refs/pull/59546/merge:refs/remotes/pull/59546/merge
---
2019-09-27T21:02:16.6746549Z     Checking rustc_plugin_impl v0.0.0 (/checkout/src/librustc_plugin)
2019-09-27T21:02:16.9564058Z     Checking rustc_resolve v0.0.0 (/checkout/src/librustc_resolve)
2019-09-27T21:02:19.7579127Z     Checking rustc_privacy v0.0.0 (/checkout/src/librustc_privacy)
2019-09-27T21:02:20.3598241Z     Checking rustc_codegen_ssa v0.0.0 (/checkout/src/librustc_codegen_ssa)
2019-09-27T21:02:20.4020509Z error: expected one of `)`, `,`, `.`, `::`, `?`, or an operator, found `{`
2019-09-27T21:02:20.4020930Z    --> src/librustc_codegen_ssa/mir/block.rs:160:65
2019-09-27T21:02:20.4021435Z     |
2019-09-27T21:02:20.4021828Z 160 |         if (bx.tcx().sess.opts.debugging_opts.insert_sideeffect {
2019-09-27T21:02:20.4022132Z     |            -                                                   -^
2019-09-27T21:02:20.4022459Z     |            |                                                   |
2019-09-27T21:02:20.4022774Z     |            unclosed delimiter                                  help: `)` may belong here
2019-09-27T21:02:20.4048653Z error: expected expression, found `)`
2019-09-27T21:02:20.4048987Z    --> src/librustc_codegen_ssa/mir/block.rs:170:5
2019-09-27T21:02:20.4049349Z     |
2019-09-27T21:02:20.4049748Z 170 |     }
2019-09-27T21:02:20.4049748Z 170 |     }
2019-09-27T21:02:20.4050005Z     |     ^ expected expression
2019-09-27T21:02:20.4050413Z 
2019-09-27T21:02:20.4087363Z error: expected one of `)`, `,`, or `|`, found `target`
2019-09-27T21:02:20.4087682Z    --> src/librustc_codegen_ssa/mir/block.rs:824:24
2019-09-27T21:02:20.4087902Z     |
2019-09-27T21:02:20.4088229Z 824 |         if let Some((_ target)) = destination.as_ref() {
2019-09-27T21:02:20.4088566Z     |                        ^^^^^^ expected one of `)`, `,`, or `|` here
2019-09-27T21:02:20.7108048Z error: unnecessary parentheses around `if` condition
2019-09-27T21:02:20.7108445Z    --> src/librustc_codegen_ssa/mir/block.rs:160:12
2019-09-27T21:02:20.7108672Z     |
2019-09-27T21:02:20.7108672Z     |
2019-09-27T21:02:20.7109386Z 160 |         if (bx.tcx().sess.opts.debugging_opts.insert_sideeffect {
2019-09-27T21:02:20.7109715Z     |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove these parentheses
2019-09-27T21:02:20.7110268Z     = note: `-D unused-parens` implied by `-D warnings`
2019-09-27T21:02:20.7110304Z 
2019-09-27T21:02:21.8230339Z error[E0308]: mismatched types
2019-09-27T21:02:21.8231817Z    --> src/librustc_codegen_ssa/mir/block.rs:587:66
2019-09-27T21:02:21.8231817Z    --> src/librustc_codegen_ssa/mir/block.rs:587:66
2019-09-27T21:02:21.8233046Z     |
2019-09-27T21:02:21.8233847Z 587 |                     helper.maybe_sideeffect(self.mir, &mut bx, &[target]);
2019-09-27T21:02:21.8234533Z     |                                                                  ^^^^^^ expected struct `rustc::mir::BasicBlock`, found reference
2019-09-27T21:02:21.8236256Z     = note: expected type `rustc::mir::BasicBlock`
2019-09-27T21:02:21.8236791Z                found type `&rustc::mir::BasicBlock`
2019-09-27T21:02:21.8236972Z 
2019-09-27T21:02:21.8561286Z error[E0308]: mismatched types
2019-09-27T21:02:21.8561286Z error[E0308]: mismatched types
2019-09-27T21:02:21.8562440Z    --> src/librustc_codegen_ssa/mir/block.rs:825:58
2019-09-27T21:02:21.8562845Z     |
2019-09-27T21:02:21.8563494Z 825 |             helper.maybe_sideeffect(self.mir, &mut bx, &[target]);
2019-09-27T21:02:21.8564047Z     |                                                          ^^^^^^ expected struct `rustc::mir::BasicBlock`, found reference
2019-09-27T21:02:21.8564839Z     = note: expected type `rustc::mir::BasicBlock`
2019-09-27T21:02:21.8565260Z                found type `&rustc::mir::BasicBlock`
2019-09-27T21:02:21.8565436Z 
2019-09-27T21:02:23.2788207Z error: aborting due to 6 previous errors
---
2019-09-27T21:02:25.8124526Z == clock drift check ==
2019-09-27T21:02:25.8142333Z   local time: Fri Sep 27 21:02:25 UTC 2019
2019-09-27T21:02:25.9886761Z   network time: Fri, 27 Sep 2019 21:02:25 GMT
2019-09-27T21:02:25.9887439Z == end clock drift check ==
2019-09-27T21:02:27.2198010Z ##[error]Bash exited with code '1'.
2019-09-27T21:02:27.2257883Z ##[section]Starting: Checkout
2019-09-27T21:02:27.2259943Z ==============================================================================
2019-09-27T21:02:27.2259999Z Task         : Get sources
2019-09-27T21:02:27.2260048Z Description  : Get sources from a repository. Supports Git, TfsVC, and SVN repositories.

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

sfanxiang · 2019-09-28T17:22:34Z

@nikomatsakis: This is now guarded under -Z insert-sideeffect. Feel free to suggest a better name.

Reviewers: I implemented @nikic's suggestion to insert sideeffect on function entry (sorry @nikic for not paying attention earlier!). Please help make sure there is:

no missing llvm.sideeffect (especially during panic/unwind)
no unnecessary llvm.sideeffect

Thank you!

bjorn3 · 2019-09-28T18:03:52Z

I implemented @nikic's suggestion to insert sideeffect on function entry

C:

void do_nothing() {}

Rust:

extern "C" {
    fn do_nothing();
}

loop {
    unsafe { do_nothing(); }
}

would be UB when performing cross language lto because of there would be no more sideeffect on call, right?

nagisa · 2019-09-28T18:58:49Z

In theory, yes, in practice… not really. The only way to currently observe LLVM exploiting the forward-progress guarantees is by calling a function that contains an infinite loop w/o fwd progress.

sfanxiang · 2019-09-28T19:14:55Z

@bjorn3

there would be no more sideeffect on call, right?

Not on call, but on loop. IMHO there shouldn't be UB on Rust side even in theory with this model.

nagisa · 2019-10-10T15:03:41Z

@bors r+

There are a couple of improvements that we might want to do in follow-ups, such as adding an intrinsic for people to insert this into their code unconditionally, at least while this whole thing is behind a flag.

Nothing that would block this PR from landing, though. Lets experiment!

bors · 2019-10-10T15:03:42Z

📌 Commit e9acfa3 has been approved by nagisa

bors · 2019-10-10T15:03:54Z

💡 This pull request was already approved, no need to approve it again.

There's another pull request that is currently being tested, blocking this pull request: resolve: Remove an incorrect assert #65140

bors · 2019-10-10T15:03:55Z

📌 Commit e9acfa3 has been approved by nagisa

bors · 2019-10-10T15:40:44Z

⌛ Testing commit e9acfa3 with merge 58b5491...

Add llvm.sideeffect to potential infinite loops and recursions LLVM assumes that a thread will eventually cause side effect. This is not true in Rust if a loop or recursion does nothing in its body, causing undefined behavior even in common cases like `loop {}`. Inserting llvm.sideeffect fixes the undefined behavior. As a micro-optimization, only insert llvm.sideeffect when jumping back in blocks or calling a function. A patch for LLVM is expected to allow empty non-terminate code by default and fix this issue from LLVM side. #28728 **UPDATE:** [Mentoring instructions here](#59546 (comment)) to unstall this PR

bors · 2019-10-10T19:30:17Z

☀️ Test successful - checks-azure
Approved by: nagisa
Pushing 58b5491 to master...

crlf0710 · 2020-03-29T10:01:18Z

@rustbot modify labels to -S-inactive

rust-highfive assigned michaelwoerister Mar 30, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 30, 2019

Centril reviewed Mar 30, 2019

View reviewed changes

src/test/run-pass/non-terminate/infinite-loop.rs Outdated Show resolved Hide resolved

src/test/run-pass/non-terminate/infinite-recursion.rs Outdated Show resolved Hide resolved

sfanxiang force-pushed the interminable-ub branch from 1d1e574 to b3848ce Compare March 30, 2019 10:44

nagisa reviewed Mar 30, 2019

View reviewed changes

nagisa added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). labels Mar 30, 2019

sfanxiang force-pushed the interminable-ub branch 4 times, most recently from 39e58a6 to 0ea0e06 Compare March 31, 2019 16:06

This comment has been minimized.

Sign in to view

sfanxiang force-pushed the interminable-ub branch from 3516db1 to 7bcfab0 Compare September 27, 2019 20:51

sfanxiang added 2 commits September 28, 2019 07:13

Gate llvm.sideeffect under -Z insert-sideeffect

10c6681

Generate llvm.sideeffect at function entry instead of call

e9acfa3

sfanxiang force-pushed the interminable-ub branch from 7bcfab0 to e9acfa3 Compare September 27, 2019 23:16

bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Oct 10, 2019

bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 10, 2019

bors merged commit e9acfa3 into rust-lang:master Oct 10, 2019

memoryruins mentioned this pull request Oct 15, 2019

LLVM loop optimization can make safe programs crash #28728

Closed

Centril mentioned this pull request Nov 11, 2019

Stabilize ! in Rust 1.41.0 #65355

Merged

Lokathor mentioned this pull request Mar 27, 2020

Comments for "https://os.phil-opp.com/freestanding-rust-binary/" phil-opp/blog_os#386

Closed

rustbot removed the S-inactive label Mar 29, 2020

sfanxiang mentioned this pull request Jun 20, 2020

Attempt to fix infinite loop miscompilation from LLVM side #73561

Closed

guevara mentioned this pull request Oct 12, 2022

C is faster and safer than Rust: benchmarked by Yandex guevara/read-it-later#8999

Open

		@@ -1,3 +1,5 @@
		// ignore-test LLVM can't prove that these loops terminate.

Add llvm.sideeffect to potential infinite loops and recursions #59546

Add llvm.sideeffect to potential infinite loops and recursions #59546

Conversation

sfanxiang commented Mar 30, 2019 • edited by nikomatsakis Loading

rust-highfive commented Mar 30, 2019

nagisa left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nagisa Mar 30, 2019 • edited Loading

Choose a reason for hiding this comment

nagisa commented Mar 30, 2019

bors commented Mar 30, 2019

bors commented Mar 30, 2019

nagisa commented Mar 30, 2019

rust-timer commented Mar 30, 2019

rust-timer commented Mar 31, 2019

sfanxiang commented Mar 31, 2019

nagisa commented Mar 31, 2019 • edited Loading

sfanxiang commented Apr 1, 2019 • edited Loading

nagisa commented Apr 1, 2019

bors commented Apr 1, 2019

bors commented Apr 1, 2019

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

oli-obk commented Apr 1, 2019

nagisa commented Sep 27, 2019

nikomatsakis commented Sep 27, 2019 • edited by pnkfelix Loading

sfanxiang commented Sep 27, 2019

rust-highfive commented Sep 27, 2019

sfanxiang commented Sep 28, 2019

bjorn3 commented Sep 28, 2019 • edited Loading

nagisa commented Sep 28, 2019

sfanxiang commented Sep 28, 2019

nagisa commented Oct 10, 2019 • edited Loading

bors commented Oct 10, 2019

bors commented Oct 10, 2019

bors commented Oct 10, 2019

bors commented Oct 10, 2019

bors commented Oct 10, 2019

crlf0710 commented Mar 29, 2020

sfanxiang commented Mar 30, 2019 •

edited by nikomatsakis

Loading

nagisa Mar 30, 2019 •

edited

Loading

nagisa commented Mar 31, 2019 •

edited

Loading

sfanxiang commented Apr 1, 2019 •

edited

Loading

nikomatsakis commented Sep 27, 2019 •

edited by pnkfelix

Loading

bjorn3 commented Sep 28, 2019 •

edited

Loading

nagisa commented Oct 10, 2019 •

edited

Loading