rustc: Update LLVM #26025

alexcrichton · 2015-06-05T03:17:33Z

This commit updates the LLVM submodule in use to the current HEAD of the LLVM
repository. This is primarily being done to start picking up unwinding support
for MSVC, which is currently unimplemented in the revision of LLVM we are using.
Along the way a few changes had to be made:

As usual, lots of C++ debuginfo bindings in LLVM changed, so there were some
significant changes to our RustWrapper.cpp
As usual, some pass management changed in LLVM, so clang was re-scrutinized to
ensure that we're doing the same thing as clang.
Some optimization options are now passed directly into the
PassManagerBuilder instead of through CLI switches to LLVM.
The NoFramePointerElim option was removed from LLVM, favoring instead the
no-frame-pointer-elim function attribute instead.
The LoopVectorize option of the LLVM optimization passes has been disabled
as it causes a divide-by-zero exception to happen in LLVM for zero-sized
types. This is reported as https://llvm.org/bugs/show_bug.cgi?id=23763

Additionally, LLVM has picked up some new optimizations which required fixing an
existing soundness hole in the IR we generate. It appears that the current LLVM
we use does not expose this hole. When an enum is moved, the previous slot in
memory is overwritten with a bit pattern corresponding to "dropped". When the
drop glue for this slot is run, however, the switch on the discriminant can
often start executing the unreachable block of the switch due to the
discriminant now being outside the normal range. This was patched over locally
for now by having the unreachable block just change to a ret void.

rust-highfive · 2015-06-05T03:17:40Z

r? @pcwalton

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

alexcrichton · 2015-06-05T03:18:03Z

r? @brson

cc @rust-lang/compiler - something to be aware of at least, and I may have updated something horribly incorrectly

pnkfelix · 2015-06-05T12:03:19Z

@eddyb notes on a comment from #23535 that we may want to restrict the ret void change so that it is only injected on the switch injected in the generated drop-glue.

sanxiyn · 2015-06-05T12:25:31Z

Apparently, LLVM PR23763 is fixed now.

alexcrichton · 2015-06-05T16:25:54Z

@pnkfelix I think we're covered on that front because the function iter_structural_ty is only called from generating the drop glue.

@sanxiyn it has indeed! I'm testing out pulling in that revision and running tests now

eddyb · 2015-06-05T17:31:40Z

@alexcrichton oh, of course, I forgot that. Maybe that machinery should be moved out of trans::base then (in the future).

alexcrichton · 2015-06-05T17:34:27Z

Looks like rust-lang/llvm@47dfcb7 did indeed fix the problems I was seeing! Updated the LLVM submodule.

brson · 2015-06-05T18:30:23Z

src/rustllvm/PassWrapper.cpp

+    unwrap(PMB)->SLPVectorize = SLPVectorize;
+    unwrap(PMB)->OptLevel = OptLevel;
+    unwrap(PMB)->LoopVectorize = LoopVectorize;
+#endif
 }


Now that the PMB opt level is set here and not through llvm::LLVMPassManagerBuilderSetOptLevel it appears that for LLVM < 7 we don't set the PMB opt level. Is that true, and is that bad?

Oh this reminded me that I meant to recompile these files against 3.5 and 3.6, and now having done so it looks like only MergeFunctions wasn't available in 3.5 but everything else is now set on all versions.

brson · 2015-06-05T18:34:23Z

r=me once you've answered my q's.

This was a tough upgrade. Good work.

alexcrichton · 2015-06-05T21:49:24Z

@bors: r=brson 0e0cc9e

bors · 2015-06-05T23:02:30Z

⌛ Testing commit 0e0cc9e with merge 2146851...

This commit updates the LLVM submodule in use to the current HEAD of the LLVM repository. This is primarily being done to start picking up unwinding support for MSVC, which is currently unimplemented in the revision of LLVM we are using. Along the way a few changes had to be made: * As usual, lots of C++ debuginfo bindings in LLVM changed, so there were some significant changes to our RustWrapper.cpp * As usual, some pass management changed in LLVM, so clang was re-scrutinized to ensure that we're doing the same thing as clang. * Some optimization options are now passed directly into the `PassManagerBuilder` instead of through CLI switches to LLVM. * The `NoFramePointerElim` option was removed from LLVM, favoring instead the `no-frame-pointer-elim` function attribute instead. * The `LoopVectorize` option of the LLVM optimization passes has been disabled as it causes a divide-by-zero exception to happen in LLVM for zero-sized types. This is reported as https://llvm.org/bugs/show_bug.cgi?id=23763 Additionally, LLVM has picked up some new optimizations which required fixing an existing soundness hole in the IR we generate. It appears that the current LLVM we use does not expose this hole. When an enum is moved, the previous slot in memory is overwritten with a bit pattern corresponding to "dropped". When the drop glue for this slot is run, however, the switch on the discriminant can often start executing the `unreachable` block of the switch due to the discriminant now being outside the normal range. This was patched over locally for now by having the `unreachable` block just change to a `ret void`.

bors · 2015-06-06T00:00:08Z

💔 Test failed - auto-win-gnu-32-nopt-t

alexcrichton · 2015-06-06T00:41:26Z

@bors: r=brson 89cb355

bors · 2015-06-06T03:38:59Z

⌛ Testing commit 89cb355 with merge 13e5306...

bors · 2015-06-06T04:30:22Z

💔 Test failed - auto-mac-64-nopt-t

alexcrichton · 2015-06-07T18:06:44Z

This is now blocked on https://llvm.org/bugs/show_bug.cgi?id=23779

bors · 2015-06-09T06:06:30Z

☔ The latest upstream changes (presumably #25627) made this pull request unmergeable. Please resolve the merge conflicts.

alexcrichton · 2015-06-12T18:02:07Z

Ok, the LLVM bug has not been fixed yet, and I had some time to do some more investigation. The end result was adding this extra commit to the LLVM branch that we're using. Still running tests locally, but I suspect it will fix that segfault at least.

re-r? @brson

bors · 2015-06-17T00:28:42Z

⌛ Testing commit 6583dda with merge 252855f...

bors · 2015-06-17T00:44:24Z

💔 Test failed - auto-mac-64-nopt-t

retep998 · 2015-06-17T00:46:59Z

Do you think you could fix this error before trying again?

In file included from /Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-nopt-t/build/src/llvm/lib/ExecutionEngine/Orc/OrcMCJITReplacement.cpp:10:
In file included from /Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-nopt-t/build/src/llvm/lib/ExecutionEngine/Orc/OrcMCJITReplacement.h:20:
/Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-nopt-t/build/src/llvm/include/llvm/ExecutionEngine/Orc/LazyEmittingLayer.h:126:66: error: only virtual member functions can be marked 'override'
                                 bool ExportedSymbolsOnly) const override {
                                                                 ^~~~~~~~
1 error generated.
make[4]: *** [/Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-nopt-t/build/obj/x86_64-apple-darwin/llvm/lib/ExecutionEngine/Orc/Release/OrcMCJITReplacement.o] Error 1
make[3]: *** [Orc/.makeall] Error 2
make[2]: *** [ExecutionEngine/.makeall] Error 2
make[2]: *** Waiting for unfinished jobs....

alexcrichton · 2015-06-17T01:31:11Z

@bors: r=brson 547418d

alexcrichton · 2015-06-17T01:45:22Z

@bors: r=brson 78ac14c

bors · 2015-06-17T02:48:29Z

⌛ Testing commit 78ac14c with merge 87f60f5...

bors · 2015-06-17T03:51:14Z

💔 Test failed - auto-mac-32-opt

This commit updates the LLVM submodule in use to the current HEAD of the LLVM repository. This is primarily being done to start picking up unwinding support for MSVC, which is currently unimplemented in the revision of LLVM we are using. Along the way a few changes had to be made: * As usual, lots of C++ debuginfo bindings in LLVM changed, so there were some significant changes to our RustWrapper.cpp * As usual, some pass management changed in LLVM, so clang was re-scrutinized to ensure that we're doing the same thing as clang. * Some optimization options are now passed directly into the `PassManagerBuilder` instead of through CLI switches to LLVM. * The `NoFramePointerElim` option was removed from LLVM, favoring instead the `no-frame-pointer-elim` function attribute instead. Additionally, LLVM has picked up some new optimizations which required fixing an existing soundness hole in the IR we generate. It appears that the current LLVM we use does not expose this hole. When an enum is moved, the previous slot in memory is overwritten with a bit pattern corresponding to "dropped". When the drop glue for this slot is run, however, the switch on the discriminant can often start executing the `unreachable` block of the switch due to the discriminant now being outside the normal range. This was patched over locally for now by having the `unreachable` block just change to a `ret void`.

alexcrichton · 2015-06-17T05:57:36Z

@bors: r=brson f9d4149

bors · 2015-06-17T06:56:16Z

⌛ Testing commit f9d4149 with merge aa00f2e...

This commit updates the LLVM submodule in use to the current HEAD of the LLVM repository. This is primarily being done to start picking up unwinding support for MSVC, which is currently unimplemented in the revision of LLVM we are using. Along the way a few changes had to be made: * As usual, lots of C++ debuginfo bindings in LLVM changed, so there were some significant changes to our RustWrapper.cpp * As usual, some pass management changed in LLVM, so clang was re-scrutinized to ensure that we're doing the same thing as clang. * Some optimization options are now passed directly into the `PassManagerBuilder` instead of through CLI switches to LLVM. * The `NoFramePointerElim` option was removed from LLVM, favoring instead the `no-frame-pointer-elim` function attribute instead. * The `LoopVectorize` option of the LLVM optimization passes has been disabled as it causes a divide-by-zero exception to happen in LLVM for zero-sized types. This is reported as https://llvm.org/bugs/show_bug.cgi?id=23763 Additionally, LLVM has picked up some new optimizations which required fixing an existing soundness hole in the IR we generate. It appears that the current LLVM we use does not expose this hole. When an enum is moved, the previous slot in memory is overwritten with a bit pattern corresponding to "dropped". When the drop glue for this slot is run, however, the switch on the discriminant can often start executing the `unreachable` block of the switch due to the discriminant now being outside the normal range. This was patched over locally for now by having the `unreachable` block just change to a `ret void`.

bors · 2015-06-17T09:13:08Z

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt

KindDragon · 2015-06-17T19:45:20Z

Congratulations! 👍 😄

frewsxcv · 2016-01-25T05:14:28Z

This caused a regression related to LLVM passes. I fixed it in #31176

LLVM was upgraded to a new version in this commit: rust-lang@f9d4149 which was part of this pull request: rust-lang#26025 Consider the following two lines from that commit: rust-lang@f9d4149#diff-a3b24dbe2ea7c1981f9ac79f9745f40aL462 rust-lang@f9d4149#diff-a3b24dbe2ea7c1981f9ac79f9745f40aL469 The purpose of these lines is to register LLVM passes. Prior to the that commit, the passes being handled were assumed to be ModulePasses (a specific type of LLVM pass) since they were being added to a ModulePass manager. After that commit, both lines were refactored (presumably in an attempt to DRY out the code), but the ModulePasses were changed to be registered to a FunctionPass manager. This change resulted in ModulePasses being run, but a Function object was being passed as a parameter to the pass instead of a Module, which resulted in segmentation faults. In this commit, I changed relevant sections of the code to check the type of the passes being added and register them to the appropriate pass manager. Closes rust-lang#31067

Register LLVM passes with the correct LLVM pass manager. LLVM was upgraded to a new version in this commit: f9d4149 which was part of this pull request: #26025 Consider the following two lines from that commit: f9d4149#diff-a3b24dbe2ea7c1981f9ac79f9745f40aL462 f9d4149#diff-a3b24dbe2ea7c1981f9ac79f9745f40aL469 The purpose of these lines is to register LLVM passes. Prior to the that commit, the passes being handled were assumed to be ModulePasses (a specific type of LLVM pass) since they were being added to a ModulePass manager. After that commit, both lines were refactored (presumably in an attempt to DRY out the code), but the ModulePasses were changed to be registered to a FunctionPass manager. This change resulted in ModulePasses being run, but a Function object was being passed as a parameter to the pass instead of a Module, which resulted in segmentation faults. In this commit, I changed relevant sections of the code to check the type of the passes being added and register them to the appropriate pass manager. Closes #31067

rust-highfive assigned pcwalton Jun 5, 2015

rust-highfive assigned brson and unassigned pcwalton Jun 5, 2015

pnkfelix mentioned this pull request Jun 5, 2015

Replace zeroing-on-drop with filling-on-drop. #23535

Merged

alexcrichton force-pushed the update-llvm branch from fc88c8b to bd572c7 Compare June 5, 2015 17:33

brson reviewed Jun 5, 2015
View reviewed changes

alexcrichton force-pushed the update-llvm branch from bd572c7 to 0e0cc9e Compare June 5, 2015 21:45

alexcrichton force-pushed the update-llvm branch from 0e0cc9e to 89cb355 Compare June 6, 2015 00:41

alexcrichton force-pushed the update-llvm branch from 89cb355 to c59700b Compare June 12, 2015 17:59

alexcrichton force-pushed the update-llvm branch from 6583dda to 547418d Compare June 17, 2015 01:31

alexcrichton force-pushed the update-llvm branch from 547418d to 78ac14c Compare June 17, 2015 01:44

bluss mentioned this pull request Jun 17, 2015

APIs stabilization metabug #24028

Closed

29 tasks

alexcrichton force-pushed the update-llvm branch from 78ac14c to f9d4149 Compare June 17, 2015 05:57

bors merged commit f9d4149 into rust-lang:master Jun 17, 2015

alexcrichton deleted the update-llvm branch June 17, 2015 16:24

alexcrichton mentioned this pull request Jun 18, 2015

MSVC: Implement 32-bit Unwinding #25869

Closed

4 tasks

dotdash mentioned this pull request Jun 18, 2015

Performance of inlined code not as expected #24489

Closed

gz mentioned this pull request Jun 20, 2015

Compiling libcore without SSE leads to LLVM ERROR: SSE register return with SSE disabled #26449

Closed

gz mentioned this pull request Jul 6, 2015

Fixes #26449 #26749

Closed

pnkfelix mentioned this pull request Jul 9, 2015

Using both --enable-debug, --enable-optimization causes an assertion failure on build #26484

Closed

frewsxcv mentioned this pull request Jan 25, 2016

Register LLVM passes with the correct LLVM pass manager. #31176

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

rustc: Update LLVM #26025

rustc: Update LLVM #26025

alexcrichton commented Jun 5, 2015

rust-highfive commented Jun 5, 2015

alexcrichton commented Jun 5, 2015

pnkfelix commented Jun 5, 2015

sanxiyn commented Jun 5, 2015

alexcrichton commented Jun 5, 2015

eddyb commented Jun 5, 2015

alexcrichton commented Jun 5, 2015

brson Jun 5, 2015

alexcrichton Jun 5, 2015

brson commented Jun 5, 2015

alexcrichton commented Jun 5, 2015

bors commented Jun 5, 2015

bors commented Jun 6, 2015

alexcrichton commented Jun 6, 2015

bors commented Jun 6, 2015

bors commented Jun 6, 2015

alexcrichton commented Jun 7, 2015

bors commented Jun 9, 2015

alexcrichton commented Jun 12, 2015

bors commented Jun 17, 2015

bors commented Jun 17, 2015

retep998 commented Jun 17, 2015

alexcrichton commented Jun 17, 2015

alexcrichton commented Jun 17, 2015

bors commented Jun 17, 2015

bors commented Jun 17, 2015

alexcrichton commented Jun 17, 2015

bors commented Jun 17, 2015

bors commented Jun 17, 2015

KindDragon commented Jun 17, 2015

frewsxcv commented Jan 25, 2016

rustc: Update LLVM #26025

rustc: Update LLVM #26025

Conversation

alexcrichton commented Jun 5, 2015

rust-highfive commented Jun 5, 2015

alexcrichton commented Jun 5, 2015

pnkfelix commented Jun 5, 2015

sanxiyn commented Jun 5, 2015

alexcrichton commented Jun 5, 2015

eddyb commented Jun 5, 2015

alexcrichton commented Jun 5, 2015

brson Jun 5, 2015

Choose a reason for hiding this comment

alexcrichton Jun 5, 2015

Choose a reason for hiding this comment

brson commented Jun 5, 2015

alexcrichton commented Jun 5, 2015

bors commented Jun 5, 2015

bors commented Jun 6, 2015

alexcrichton commented Jun 6, 2015

bors commented Jun 6, 2015

bors commented Jun 6, 2015

alexcrichton commented Jun 7, 2015

bors commented Jun 9, 2015

alexcrichton commented Jun 12, 2015

bors commented Jun 17, 2015

bors commented Jun 17, 2015

retep998 commented Jun 17, 2015

alexcrichton commented Jun 17, 2015

alexcrichton commented Jun 17, 2015

bors commented Jun 17, 2015

bors commented Jun 17, 2015

alexcrichton commented Jun 17, 2015

bors commented Jun 17, 2015

bors commented Jun 17, 2015

KindDragon commented Jun 17, 2015

frewsxcv commented Jan 25, 2016