Skip to content

/rust

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

rustc: Update LLVM #26025

Merged
merged 1 commit into from Jun 17, 2015

Conversation

Reviewers
No reviews
Assignees

@brson brson

Labels
None yet
Projects
None yet
Milestone
No milestone
@alexcrichton
Copy link
Member

alexcrichton commented Jun 5, 2015

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 rust-highfive assigned pcwalton Jun 5, 2015

@rust-highfive

This comment has been minimized.

Sign in to view
Copy link
Collaborator

rust-highfive commented Jun 5, 2015

r? @pcwalton

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

This comment has been minimized.

Sign in to view
Copy link
Member Author

alexcrichton commented Jun 5, 2015

r? @brson

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

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

@pnkfelix pnkfelix referenced this pull request Jun 5, 2015

Merged

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

@pnkfelix

This comment has been minimized.

Sign in to view
Copy link
Member

pnkfelix commented Jun 5, 2015

@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

This comment has been minimized.

Sign in to view
Copy link
Member

sanxiyn commented Jun 5, 2015

Apparently, LLVM PR23763 is fixed now.
@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member Author

alexcrichton commented Jun 5, 2015

@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

This comment has been minimized.

Sign in to view
Copy link
Member

eddyb commented Jun 5, 2015

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

@alexcrichton alexcrichton force-pushed the alexcrichton:update-llvm branch from fc88c8b to bd572c7 Jun 5, 2015

@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member Author

alexcrichton commented Jun 5, 2015

Looks like rust-lang/llvm@47dfcb7 did indeed fix the problems I was seeing! Updated the LLVM submodule.
src/rustllvm/PassWrapper.cpp Outdated
unwrap(PMB)->SLPVectorize = SLPVectorize;
unwrap(PMB)->OptLevel = OptLevel;
unwrap(PMB)->LoopVectorize = LoopVectorize;
#endif
}

This comment has been minimized.

Sign in to view
Copy link
@brson

brson Jun 5, 2015

Contributor

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?

This comment has been minimized.

Sign in to view
Copy link
@alexcrichton

alexcrichton Jun 5, 2015

Author Member

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.
src/rustllvm/RustWrapper.cpp
#if LLVM_VERSION_MINOR <= 6
context
#endif
)));
#else

This comment has been minimized.

Sign in to view
Copy link
@brson

brson Jun 5, 2015

Contributor

Yikes... that's lovely.

This comment has been minimized.

Sign in to view
Copy link
@alexcrichton

alexcrichton Jun 5, 2015

Author Member

Yeah this file is... a mess. Supporting multiple LLVM versions is definitely not our forte.
src/test/codegen/loads.rs
@@ -46,7 +46,7 @@ pub fn small_array_alignment(x: [i8; 4]) -> [i8; 4] {
// dependent alignment
#[no_mangle]
pub fn small_struct_alignment(x: Bytes) -> Bytes {
// CHECK: [[VAR:%[0-9]+]] = load i32* %{{.*}}, align 1
// CHECK: [[VAR:%[0-9]+]] = load i32, i32* %{{.*}}, align 1
// CHECK: ret i32 [[VAR]]
x

This comment has been minimized.

Sign in to view
Copy link
@brson

brson Jun 5, 2015

Contributor

What are these test changes about?

This comment has been minimized.

Sign in to view
Copy link
@eddyb

eddyb Jun 5, 2015

Member

LLVM is switching to opaque pointers, so instructions working with pointers have to supply both the pointer type and the pointee in the interim.
The final result will have only the pointee type, the pointer type always being ptr or something like that.

This comment has been minimized.

Sign in to view
Copy link
@alexcrichton

alexcrichton Jun 5, 2015

Author Member

Yeah this was just changes syntactically in the IR self, semantically nothing changed here.
@brson

This comment has been minimized.

Sign in to view
Copy link
Contributor

brson commented Jun 5, 2015

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

This was a tough upgrade. Good work.

@alexcrichton alexcrichton force-pushed the alexcrichton:update-llvm branch from bd572c7 to 0e0cc9e Jun 5, 2015

@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member Author

alexcrichton commented Jun 5, 2015

@bors: r=brson 0e0cc9e
@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented Jun 5, 2015

⌛️ Testing commit 0e0cc9e with merge 2146851...

bors added a commit that referenced this pull request Jun 5, 2015

@bors
Auto merge of #26025 - alexcrichton:update-llvm, r=brson 
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`.
2146851
@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented Jun 6, 2015

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

@alexcrichton alexcrichton force-pushed the alexcrichton:update-llvm branch from 0e0cc9e to 89cb355 Jun 6, 2015

@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member Author

alexcrichton commented Jun 6, 2015

@bors: r=brson 89cb355
@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented Jun 6, 2015

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

bors added a commit that referenced this pull request Jun 6, 2015

@bors
Auto merge of #26025 - alexcrichton:update-llvm, r=brson 
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`.
13e5306
@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented Jun 6, 2015

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

This comment has been minimized.

Sign in to view
Copy link
Member Author

alexcrichton commented Jun 7, 2015

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

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented Jun 9, 2015

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

@alexcrichton alexcrichton force-pushed the alexcrichton:update-llvm branch from 89cb355 to c59700b Jun 12, 2015

@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member Author

alexcrichton commented Jun 12, 2015

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

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented Jun 17, 2015

⌛️ Testing commit 6583dda with merge 252855f...
@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented Jun 17, 2015

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

This comment has been minimized.

Sign in to view
Copy link
Member

retep998 commented Jun 17, 2015

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 alexcrichton force-pushed the alexcrichton:update-llvm branch from 6583dda to 547418d Jun 17, 2015

@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member Author

alexcrichton commented Jun 17, 2015

@bors: r=brson 547418d

@alexcrichton alexcrichton force-pushed the alexcrichton:update-llvm branch from 547418d to 78ac14c Jun 17, 2015

@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member Author

alexcrichton commented Jun 17, 2015

@bors: r=brson 78ac14c

bors added a commit that referenced this pull request Jun 17, 2015

@bors
Auto merge of #26025 - alexcrichton:update-llvm, r=brson 
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`.
87f60f5
@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented Jun 17, 2015

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

@bluss bluss referenced this pull request Jun 17, 2015

Closed

APIs stabilization metabug #24028

5 of 29 tasks complete
@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented Jun 17, 2015

💔 Test failed - auto-mac-32-opt
@alexcrichton
rustc: Update LLVM 
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`.
Loading status checks…
f9d4149

@alexcrichton alexcrichton force-pushed the alexcrichton:update-llvm branch from 78ac14c to f9d4149 Jun 17, 2015

@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member Author

alexcrichton commented Jun 17, 2015

@bors: r=brson f9d4149
@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented Jun 17, 2015

⌛️ Testing commit f9d4149 with merge aa00f2e...

bors added a commit that referenced this pull request Jun 17, 2015

@bors
Auto merge of #26025 - alexcrichton:update-llvm, r=brson 
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`.
Loading status checks…
aa00f2e
@bors

@bors bors merged commit f9d4149 into rust-lang:master Jun 17, 2015
2 checks passed

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details

@alexcrichton alexcrichton deleted the alexcrichton:update-llvm branch Jun 17, 2015

@KindDragon

This comment has been minimized.

Sign in to view
Copy link

KindDragon commented Jun 17, 2015

Congratulations! 👍 😄

@alexcrichton alexcrichton referenced this pull request Jun 18, 2015

Closed

MSVC: Implement 32-bit Unwinding #25869

4 of 4 tasks complete

@dotdash dotdash referenced this pull request Jun 18, 2015

Closed

Performance of inlined code not as expected #24489

@gz gz referenced this pull request Jun 20, 2015

Open

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

@gz gz referenced this pull request Jul 6, 2015

Closed

Fixes #26449 #26749

@pnkfelix pnkfelix referenced this pull request Jul 9, 2015

Closed

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

@frewsxcv

This comment has been minimized.

Sign in to view
Copy link
Member

frewsxcv commented Jan 25, 2016

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

frewsxcv added a commit to frewsxcv/rust that referenced this pull request Jan 25, 2016

@frewsxcv
Register LLVM passes with the correct LLVM pass manager. 
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
d942621

@frewsxcv frewsxcv referenced this pull request Jan 25, 2016

Merged

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

bors added a commit that referenced this pull request Jan 25, 2016

@bors
Auto merge of #31176 - frewsxcv:incorrect-pass-kind, r=dotdash 
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
c22cb53

rthomas added a commit to rthomas/rust that referenced this pull request Feb 1, 2016

@frewsxcv @rthomas
Register LLVM passes with the correct LLVM pass manager. 
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
dee3e69
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.