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

Change opt-level from 2 back to 3 #67878

Merged
merged 1 commit into from Jan 31, 2020
Merged

Change opt-level from 2 back to 3 #67878

merged 1 commit into from Jan 31, 2020

Conversation

@Others
Copy link
Contributor

Others commented Jan 4, 2020

In Cargo.toml, the opt-level for release and bench was overridden to be 2. This was to work around a problem with LLVM 7. However, rust no longer uses LLVM 7, so this is hopefully no longer needed?

I tried a little bit to replicate the original problem, and could not. I think running this through CI is the best way to smoke test this :) Even if things break dramatically, the comment should be updated to reflect that things are still broken with LLVM 9.

I'm just getting started playing with the compiler, so apologies if I've missed an obvious problem here.

fixes #52378

(possibly relevant is the current update to LLVM 10)

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented Jan 4, 2020

r? @nikomatsakis

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

@Mark-Simulacrum

This comment has been minimized.

Copy link
Member

Mark-Simulacrum commented Jan 5, 2020

I suspect things are still broken; that comment has been around since I can remember. However, we might as well let this inch its way through the queue. @bors rollup=never r+

It's also I believe true that we've not really seen appreciable performance gains when doing this, so it may just generally not be worth it. (I am unsure of the costs in compile time of rustc itself, but would not be surprised if they're non-marginal). I suspect this will fail anyway.

r? @Mark-Simulacrum

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jan 5, 2020

📌 Commit c7f44b9 has been approved by Mark-Simulacrum

@mati865

This comment has been minimized.

Copy link
Contributor

mati865 commented Jan 5, 2020

Previously identical chenge has passed CI but made subsequent PRs fail spuriously. That makes this PR quite high risk.

@Mark-Simulacrum

This comment has been minimized.

Copy link
Member

Mark-Simulacrum commented Jan 5, 2020

I think enough time had passed that it may be worth trying again. However, one thing I did want to do but forgot - @bors r- try @rust-timer queue

Let's gather perf stats before landing.

@rust-timer

This comment has been minimized.

Copy link

rust-timer commented Jan 5, 2020

Awaiting bors try build completion

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jan 5, 2020

⌛️ Trying commit c7f44b9 with merge c8c2243...

bors added a commit that referenced this pull request Jan 5, 2020
Change opt-level from 2 back to 3

In Cargo.toml, the opt-level for `release` and `bench` was overridden to be 2. This was to work around a problem with LLVM 7. However, rust no longer uses LLVM 7, so this is hopefully no longer needed?

I tried a little bit to replicate the original problem, and could not. I think running this through CI is the best way to smoke test this :) Even if things break dramatically, the comment should be updated to reflect that things are still broken with LLVM 9.

I'm just getting started playing with the compiler, so apologies if I've missed an obvious problem here.

fixes #52378

(possibly relevant is the [current update to LLVM 10](#52378))
@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jan 5, 2020

☀️ Try build successful - checks-azure
Build commit: c8c2243 (c8c22433c5b3e436a1837ce84de8eacc5586de6d)

@rust-timer

This comment has been minimized.

Copy link

rust-timer commented Jan 5, 2020

Queued c8c2243 with parent 7785834, future comparison URL.

@rust-timer

This comment has been minimized.

Copy link

rust-timer commented Jan 5, 2020

Finished benchmarking try commit c8c2243, comparison URL.

@bjorn3

This comment has been minimized.

Copy link
Contributor

bjorn3 commented Jan 5, 2020

const_eval_raw is about 16% slower.

@Others

This comment has been minimized.

Copy link
Contributor Author

Others commented Jan 5, 2020

@bjorn3 I haven't used rust-timer before. Where are you pulling that number from?
I do see that the ctfe tests have some unfortunate high variance

@bjorn3

This comment has been minimized.

Copy link
Contributor

bjorn3 commented Jan 5, 2020

First click on the benchmark group (ctfe-stress-4-check), then click on the percentage corresponding to a specific benchmark (10.7% for clean) You will then go to a page which shows info for every query.

@Others

This comment has been minimized.

Copy link
Contributor Author

Others commented Jan 5, 2020

@bjorn3 ah, thanks!

Digging into the results, it seems that this change improves incremental speed by a few percent on quite a few of the test cases. This seems like a good initial sign! const_eval_raw is the only query I can find that significantly regressed.

I think this PR probably is worth landing, assuming the const_eval_raw regression can be mitigated. (And we try and ensure it's not going to cause spurious failures in the future.)

@Mark-Simulacrum How do you recommend I proceed here?

@Aaron1011

This comment has been minimized.

Copy link
Contributor

Aaron1011 commented Jan 5, 2020

I ran perf on rustc 1.42.0-nightly (119307a83 2019-12-31) and the try build for this PR (c8c22433c5b3e436a1837ce84de8eacc5586de6d) against ctfe-stress-4.

The slowdown appears to be coming from the body of const_eval_raw_provider. Here's the relevant snippets of annotated assembly:

Nightly:

  7.37 │      → callq  rustc_mir::interpret::step::<impl rustc_mir::interpret::eval_context::InterpCx<M>>::step                                                                                                                              ▒
 11.35 │        movzbl 0x20(%rsp),%edx                                                                                                                                                                                                       ▒
  6.80 │        movzbl 0x21(%rsp),%ecx                                                                                                                                                                                                       ▒
  1.14 │        movzbl 0x28(%rsp),%eax                                                                                                                                                                                                       ▒
  1.70 │        movups (%rbx),%xmm0                                                                                                                                                                                                          ▒
 11.94 │        movups 0x10(%rbx),%xmm1                                                                                                                                                                                                      ▒
  6.81 │        movups 0x20(%rbx),%xmm2                                                                                                                                                                                                      ▒
  6.85 │        movups 0x30(%rbx),%xmm3                                                                                                                                                                                                      ▒
       │        movaps %xmm0,0xa0(%rsp)                                                                                                                                                                                                      ▒
  9.11 │        movaps %xmm1,0xb0(%rsp)                                                                                                                                                                                                      ▒
  7.34 │        movaps %xmm2,0xc0(%rsp)                                                                                                                                                                                                      ▒
  5.11 │        movaps %xmm3,0xd0(%rsp)                                                                                                                                                                                                      ▒
       │        mov    0x3f(%rbx),%rsi                                                                                                                                                                                                       ▒
  9.66 │        mov    %rsi,0xdf(%rsp)                                                                                                                                                                                                       ▒
  5.15 │        cmp    $0x1,%dl                                                                                                                                                                                                              ▒

This PR:

  2.55 │      → callq  rustc_mir::interpret::step::<impl rustc_mir::interpret::eval_context::InterpCx<M>>::step                                                                                                                              ▒
  2.35 │        movups 0x130(%rsp),%xmm0                                                                                                                                                                                                     ▒
  0.10 │        movaps %xmm0,0x60(%rsp)                                                                                                                                                                                                      ▒
 67.80 │        movups 0xf0(%rsp),%xmm0                                                                                                                                                                                                      ▒
       │        movups 0x100(%rsp),%xmm1                                                                                                                                                                                                     ▒
  0.10 │        movups 0x110(%rsp),%xmm2                                                                                                                                                                                                     ▒
       │        movups 0x120(%rsp),%xmm3                                                                                                                                                                                                     ▒
  3.53 │        movaps %xmm3,0x50(%rsp)                                                                                                                                                                                                      ▒
       │        movaps %xmm2,0x40(%rsp)                                                                                                                                                                                                      ▒
       │        movaps %xmm1,0x30(%rsp)                                                                                                                                                                                                      ▒
  3.22 │        movaps %xmm0,0x20(%rsp)                                                                                                                                                                                                      ▒
 12.67 │        cmpb   $0x1,0x20(%rsp)   

With this branch, LLVM appears to be generating more SIMD instructions. However, the total percentage for the the various mov instructions seems to be about the same. The real difference seems to be the cmp instruction - on Nightly, it's comparing against a register. On this branch, it's performing a load from memory.

I think this corresponds to checking the discriminant of the Result returned by InterpCx::step.

I'm not 100% sure that this analysis is correct. However, it appears that part of this regression may be due to LLVM codegenning InterpCx::step such that the discriminant of the result is stored on the stack, rather than in a register.

EDIT: I didn't realize that %dl is part of %edx. The discriminant isn't actually stored directly in a register - it's loaded via movzbl 0x20(%rsp),%edx

@Others

This comment has been minimized.

Copy link
Contributor Author

Others commented Jan 5, 2020

@Aaron1011

Very interesting! I'm assuming that the expensive call chain is:

const_eval_raw_provider => eval_body_using_ecx => InterpCx::run => InterpCx::step

My reading of the assembly is that on nightly LLVM is loading some part of the return value at the start (from 0x20(%rsp)), then doing stuff, then branching on that part of the return value:

  7.37 │      → callq  rustc_mir::interpret::step::<impl rustc_mir::interpret::eval_context::InterpCx<M>>::step                                                                                                                              ▒
 11.35 │        movzbl 0x20(%rsp),%edx  # ret value loaded from 0x20(%rsp)                                                                                                                                                                                             ▒
[SNIP: instructions don't touch %edx]
  5.15 │        cmp    $0x1,%dl         # ret value used for comparison                                                                                                                                                                                                           ▒

(Note: 77.81 on movs, 5.15 on cmps)

After this patch, LLVM doesn't bother loading that part of the ret value till the end:

  2.55 │      → callq  rustc_mir::interpret::step::<impl rustc_mir::interpret::eval_context::InterpCx<M>>::step                                                                                                                              ▒
  2.35 │        movups 0x130(%rsp),%xmm0                                                                                                                                                                                                     ▒
[SNIP: instructions don't touch 0x20(%rsp)]
  3.22 │        movaps %xmm0,0x20(%rsp)   # ret value loaded from 0x20(%rsp)                                                                                                                                                                                                   ▒
 12.67 │        cmpb   $0x1,0x20(%rsp)    # ret value loaded _AGAIN_ from 0x20(%rsp)

(Note: 77.1 on movs, 12.67 on cmps)

I wonder if this double load is hurting pipelining or instruction parallelism in some subtle way. This just seems like unlucky codegen from LLVM.

Perhaps one idea is to mark InterpCx::step as inline or inline(always). step is only ever called from the tiny function run, but the direct call seems to indicate that it's not being inlined (perhaps because of the length of the implementation of step). That might churn the IR enough to give us better performing assembly. This would be an easy thing to try, and isn't even particularly hacky -- it seems step might want to be inline anyway. What do you think of that idea?

@Aaron1011

This comment has been minimized.

Copy link
Contributor

Aaron1011 commented Jan 5, 2020

After this patch, LLVM doesn't bother loading that part of the ret value till the end:

I'm not sure that that's correct. I think LLVM is loading the return value first on both nightly and this branch. However, due to opt-level=3, it ended up using additional SIMD instructions on this branch. Note how the mov instruction totals are almost identical.

Marking step as inline seems like it could be worth a shot. However, I think it would be a good idea to try to determine why LLVM is no longer storing (what I think is) the discriminant in a register. t might just be a deliberate (but unfortunate) decision by LLVM, but it seems surprising to me that a higher optimization level should cause LLVM to avoid using a register.

@nagisa

This comment has been minimized.

Copy link
Contributor

nagisa commented Jan 5, 2020

I’m pretty confident there’s no real point in attempting to operate on a register here. The memory location in question ought to be in the L1 cache – it has been just written to the memory address in question after all.

@Others

This comment has been minimized.

Copy link
Contributor Author

Others commented Jan 6, 2020

Here’s my hypothesis:

Register is still faster than cache. The original code does the load from 0x20(%rsp) to %edx first. There isn’t a store to that address, so that can be totally pipelined with the vectorized movs. In the new code, the load from 0x20(%rsp) is only at the end — it cannot be pipelined properly.

@Others Others force-pushed the Others:opt-3 branch from c7f44b9 to 2a9cbe1 Jan 6, 2020
@Others

This comment has been minimized.

Copy link
Contributor Author

Others commented Jan 6, 2020

Okay, I added an #[inline(always)]. Comparing naively versus nightly on my local machine, this seems to have fixed the regression. (Fingers crossed.)

@Mark-Simulacrum (or someone else with bors privileges), can we get another try + rust-timer run?

@Aaron1011

This comment has been minimized.

Copy link
Contributor

Aaron1011 commented Jan 14, 2020

I'm kinda confused why there seems to be a test failure with no diagnostic output -- scary.

I think this is just the result of a command in the Makefile exiting with a nonzero status:

2020-01-13T01:30:53.0880282Z [ "`wc -c < /checkout/obj/build/x86_64-unknown-linux-gnu/test/run-make/wasm-stringify-ints-small/wasm-stringify-ints-small/foo.wasm`" -lt "20500" ]
2020-01-13T01:30:53.0880635Z Makefile:5: recipe for target 'all' failed

However, it seems extremely alarming that switching to opt-level=3 caused the size of a program built by the stage2 compiler to become larger. It looks like the behavior of the stage2 compiler was changed by the optimization level increase, which definitely shouldn't happen.

@nikic

This comment has been minimized.

Copy link
Contributor

nikic commented Jan 14, 2020

Does the opt-level here only affect the compiler itself or also libcore/libstd builds? If the latter, then that could result in a program size increase.

@Aaron1011

This comment has been minimized.

Copy link
Contributor

Aaron1011 commented Jan 14, 2020

Thats a good point - I think it affects every crate. That's much less concerning - hopefully the size impact isn't too high.

@Mark-Simulacrum

This comment has been minimized.

Copy link
Member

Mark-Simulacrum commented Jan 14, 2020

This is an increase of 2,299 bytes which feels pretty significant to me, but I don't have a lot of context here. Certainly @jamesmunns has indicated to me I believe that this is pretty significant for embedded.

Could you try to investigate where the size increase is coming from? That is, is it spread out across all of libcore/std or a few functions getting significantly larger?

@pnkfelix

This comment has been minimized.

Copy link
Member

pnkfelix commented Jan 16, 2020

This is an increase of 2,299 bytes which feels pretty significant to me, but I don't have a lot of context here. Certainly @jamesmunns has indicated to me I believe that this is pretty significant for embedded.

Could you try to investigate where the size increase is coming from? That is, is it spread out across all of libcore/std or a few functions getting significantly larger?

(also, we might want to consider the possiblilty that the failures due to lack of disk and OOMs in the earlier crater run are somehow connected to the code size increase, no?)

@Mark-Simulacrum

This comment has been minimized.

Copy link
Member

Mark-Simulacrum commented Jan 16, 2020

I suspect no -- historically we've seen sporadic oom and disk full errors sporadically on entirely clean runs too.

@Mark-Simulacrum

This comment has been minimized.

Copy link
Member

Mark-Simulacrum commented Jan 19, 2020

I would like to see us track down the size diff in that particular test before moving forward. twiggy or a similar tool run on the output from master and this branch should be helpful.

@JohnCSimon

This comment has been minimized.

Copy link
Member

JohnCSimon commented Jan 26, 2020

Ping from triage: @Others this PR has sat idle for a week, can you please post your status?

@Others

This comment has been minimized.

Copy link
Contributor Author

Others commented Jan 26, 2020

Sorry, have had a couple deadlines outside of this work. Will get back to this ASAP

@Others Others force-pushed the Others:opt-3 branch from 2a9cbe1 to 74b4c54 Jan 30, 2020
@Others

This comment has been minimized.

Copy link
Contributor Author

Others commented Jan 30, 2020

After investigating, I believe the difference is almost entirely in the size of the dlmalloc::dlmalloc::Dlmalloc::malloc function. I'm not sure why, but I can confirm that this is the only thing that's getting massively blown up.

Twiggy output pre this PR:

 Shallow Bytes │ Shallow % │ Item                                                                                                                                                                           
───────────────┼───────────┼───────────────────────────────────────────────────────────────────────────────                                                                                                 
          3518 ┊    17.26% ┊ foo                                                                                                                                                                            
          3436 ┊    16.86% ┊ dlmalloc::dlmalloc::Dlmalloc::malloc::h5191837f74aa063b                                                                                                                        
          2786 ┊    13.67% ┊ "function names" subsection                                                                                                                                                    
          1171 ┊     5.75% ┊ core::fmt::write::h0ce3b15765a50a38                                                                                                                                            
          1091 ┊     5.35% ┊ <&T as core::fmt::Display>::fmt::h8a37c3d9d7b52c10                                                                                                                             
          1017 ┊     4.99% ┊ dlmalloc::dlmalloc::Dlmalloc::free::he974a440dac0e703                                                                                                                          
           835 ┊     4.10% ┊ data[0]                                                                                                                                                                        
           791 ┊     3.88% ┊ core::fmt::Formatter::pad_integral::hda797e1e16145143                                                                                                                          
           785 ┊     3.85% ┊ __rdl_realloc                                                                                                                                                                  
           706 ┊     3.46% ┊ dlmalloc::dlmalloc::Dlmalloc::dispose_chunk::h2ab4f6a050146e3d                                                                                                                 
           481 ┊     2.36% ┊ data[1]                                                                                                                                                                        
           396 ┊     1.94% ┊ __rdl_alloc                                                                                                                                                                    
           365 ┊     1.79% ┊ <&mut W as core::fmt::Write>::write_char::he9f72744d97cef6e                                                                                                                    
           364 ┊     1.79% ┊ core::fmt::num::imp::fmt_u64::h6b8bd0148369b5f2                                                                                                                                
           332 ┊     1.63% ┊ dlmalloc::dlmalloc::Dlmalloc::insert_large_chunk::h9c2c0eddd01a2805                                                                                                            
           322 ┊     1.58% ┊ dlmalloc::dlmalloc::Dlmalloc::unlink_large_chunk::h971e5e4ddf7fb69e                                                                                                            
           205 ┊     1.01% ┊ alloc::raw_vec::RawVec<T,A>::reserve::h8b68b4c50816a33e                                                                                                                        
           162 ┊     0.79% ┊ core::result::unwrap_failed::hf27cc13e099ddfcf                                                                                                                                 
           132 ┊     0.65% ┊ core::panicking::panic_bounds_check::h281ad44a05ec4aee                                                                                                                         
           123 ┊     0.60% ┊ std::panicking::rust_panic_with_hook::h0cb0cfbfcae4d325                                                                                                                        
           118 ┊     0.58% ┊ <&mut W as core::fmt::Write>::write_fmt::h9257c36ec995818d                                                                                                                     
<SNIP>

After applying this PR:

ubuntu@ip-172-31-23-149:~/rust$ twiggy top /home/ubuntu/rust/build/x86_64-unknown-linux-gnu/test/run-make/wasm-stringify-ints-small/wasm-stringify-ints-small/foo.wasm                                      
 Shallow Bytes │ Shallow % │ Item                                                                                                                                                                           
───────────────┼───────────┼───────────────────────────────────────────────────────────────────────────────
          6256 ┊    25.41% ┊ dlmalloc::dlmalloc::Dlmalloc::malloc::h41b2f4cb262befbb
          3518 ┊    14.29% ┊ foo
          2642 ┊    10.73% ┊ "function names" subsection
          1974 ┊     8.02% ┊ dlmalloc::dlmalloc::Dlmalloc::free::h74082b2fc321a532
          1660 ┊     6.74% ┊ dlmalloc::dlmalloc::Dlmalloc::dispose_chunk::h194d309ddaa42708
          1158 ┊     4.70% ┊ core::fmt::write::h7a56f8be98585755
          1105 ┊     4.49% ┊ <&T as core::fmt::Display>::fmt::ha36b0b1ae11f94a9
          1094 ┊     4.44% ┊ __rdl_realloc
           831 ┊     3.37% ┊ data[0]
           791 ┊     3.21% ┊ core::fmt::Formatter::pad_integral::h2884a891601c317e
           481 ┊     1.95% ┊ data[1]
           402 ┊     1.63% ┊ __rdl_alloc
           365 ┊     1.48% ┊ <&mut W as core::fmt::Write>::write_char::h7c7a8ec042aeecbd
           364 ┊     1.48% ┊ core::fmt::num::imp::fmt_u64::h20314ec5886669d6
           205 ┊     0.83% ┊ alloc::raw_vec::RawVec<T,A>::reserve::h6b68995b555c2ec7
           162 ┊     0.66% ┊ core::result::unwrap_failed::haa7e7a77a7937368
           132 ┊     0.54% ┊ core::panicking::panic_bounds_check::ha6acab54c4f53c2d
           123 ┊     0.50% ┊ std::panicking::rust_panic_with_hook::h9c90ba24f7d72c9c
           118 ┊     0.48% ┊ <&mut W as core::fmt::Write>::write_fmt::h3f4eaeca77ac8b69
<SNIP>

Twiggy diff output:

 Delta Bytes │ Item
─────────────┼────────────────────────────────────────────────────────────────────
       +6256 ┊ dlmalloc::dlmalloc::Dlmalloc::malloc::h41b2f4cb262befbb
       -3436 ┊ dlmalloc::dlmalloc::Dlmalloc::malloc::h5191837f74aa063b
       +1974 ┊ dlmalloc::dlmalloc::Dlmalloc::free::h74082b2fc321a532
       +1660 ┊ dlmalloc::dlmalloc::Dlmalloc::dispose_chunk::h194d309ddaa42708
       -1171 ┊ core::fmt::write::h0ce3b15765a50a38
       +1158 ┊ core::fmt::write::h7a56f8be98585755
       +1105 ┊ <&T as core::fmt::Display>::fmt::ha36b0b1ae11f94a9
       -1091 ┊ <&T as core::fmt::Display>::fmt::h8a37c3d9d7b52c10
       -1017 ┊ dlmalloc::dlmalloc::Dlmalloc::free::he974a440dac0e703
        +791 ┊ core::fmt::Formatter::pad_integral::h2884a891601c317e
        -791 ┊ core::fmt::Formatter::pad_integral::hda797e1e16145143
        -706 ┊ dlmalloc::dlmalloc::Dlmalloc::dispose_chunk::h2ab4f6a050146e3d
        +365 ┊ <&mut W as core::fmt::Write>::write_char::h7c7a8ec042aeecbd
        -365 ┊ <&mut W as core::fmt::Write>::write_char::he9f72744d97cef6e
        +364 ┊ core::fmt::num::imp::fmt_u64::h20314ec5886669d6
        -364 ┊ core::fmt::num::imp::fmt_u64::h6b8bd0148369b5f2
        -332 ┊ dlmalloc::dlmalloc::Dlmalloc::insert_large_chunk::h9c2c0eddd01a2805
        -322 ┊ dlmalloc::dlmalloc::Dlmalloc::unlink_large_chunk::h971e5e4ddf7fb69e
        +309 ┊ __rdl_realloc
        +205 ┊ alloc::raw_vec::RawVec<T,A>::reserve::h6b68995b555c2ec7
        -347 ┊ ... and 61 more.
       +4245 ┊ Σ [81 Total Rows]

I kinda doubt this should be a blocker for the PR? Would love some more review feedback.

@Mark-Simulacrum

This comment has been minimized.

Copy link
Member

Mark-Simulacrum commented Jan 30, 2020

Interesting! Looks like the dlmalloc functions are somewhat big. Given that it's just the default allocator, and not actually mandatory (i.e. most wasm executables that care about size will likely switch to some alternative), I imagine that we can land this.

Looks like there's still a comment left to be added about the #[inline(always)] we've added and once that's in I believe we can merge.

@Others Others force-pushed the Others:opt-3 branch from 74b4c54 to dd04153 Jan 30, 2020
In Cargo.toml, the opt-level for `release` and `bench` was
overridden to be 2. This was to work around a problem with LLVM
7. However, rust no longer uses LLVM 7, so this is no longer
needed.

This creates a small compile time regression in MIR constant eval,
so I've added a #[inline(always)] on the `step` function used in
const eval

Also creates a binary size increase in wasm-stringify-ints-small,
so I've bumped the limit there.
@Others Others force-pushed the Others:opt-3 branch from dd04153 to 0d52c56 Jan 30, 2020
@Others

This comment has been minimized.

Copy link
Contributor Author

Others commented Jan 30, 2020

@Mark-Simulacrum I've added the comment :)

@Mark-Simulacrum

This comment has been minimized.

Copy link
Member

Mark-Simulacrum commented Jan 30, 2020

@bors r+ rollup=never

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jan 30, 2020

📌 Commit 0d52c56 has been approved by Mark-Simulacrum

bors added a commit that referenced this pull request Jan 31, 2020
Change opt-level from 2 back to 3

In Cargo.toml, the opt-level for `release` and `bench` was overridden to be 2. This was to work around a problem with LLVM 7. However, rust no longer uses LLVM 7, so this is hopefully no longer needed?

I tried a little bit to replicate the original problem, and could not. I think running this through CI is the best way to smoke test this :) Even if things break dramatically, the comment should be updated to reflect that things are still broken with LLVM 9.

I'm just getting started playing with the compiler, so apologies if I've missed an obvious problem here.

fixes #52378

(possibly relevant is the [current update to LLVM 10](#67759))
@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jan 31, 2020

⌛️ Testing commit 0d52c56 with merge 138c50f...

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jan 31, 2020

☀️ Test successful - checks-azure
Approved by: Mark-Simulacrum
Pushing 138c50f to master...

@bors bors added the merged-by-bors label Jan 31, 2020
@bors bors merged commit 0d52c56 into rust-lang:master Jan 31, 2020
5 checks passed
5 checks passed
homu Test successful
Details
pr Build #20200130.53 succeeded
Details
pr (Linux mingw-check) Linux mingw-check succeeded
Details
pr (Linux x86_64-gnu-llvm-7) Linux x86_64-gnu-llvm-7 succeeded
Details
pr (Linux x86_64-gnu-tools) Linux x86_64-gnu-tools succeeded
Details
@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented Jan 31, 2020

📣 Toolstate changed by #67878!

Tested on commit 138c50f.
Direct link to PR: #67878

💔 rustc-guide on linux: test-pass → test-fail (cc @JohnTitor @amanjeev @spastorino @mark-i-m, @rust-lang/infra).

rust-highfive added a commit to rust-lang-nursery/rust-toolstate that referenced this pull request Jan 31, 2020
Tested on commit rust-lang/rust@138c50f.
Direct link to PR: <rust-lang/rust#67878>

💔 rustc-guide on linux: test-pass → test-fail (cc @JohnTitor @amanjeev @spastorino @mark-i-m, @rust-lang/infra).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

You can’t perform that action at this time.