LLVM upgrade

[sanxiyn]

Let's upgrade LLVM to the latest trunk.

Since LLVM upgrades are currently disruptive to the infrastructure, all of the following should be done together:

• LLVM upgrade
• Segmented stack support for ARM (Implement __morestack for ARM #4489)
• Dealing with current LLVM patches (mostly GC-related)

[brson]

Oops, I didn't see this and opened #5401. I'll reproduce my comments here.

[brson]

Probably should also incorporate #3775 once we rebase to trunk.

Consider #5403 too.

My wip llvm removes the GC patches, removes clang and adds your ARM patches. It doesn't rebase onto LLVM trunk, though, nor resolve #3775, which will probably be solved by resetting compiler-rt to trunk and dropping our patches there.

I'm going to test this here today, but I'll be out of the office most of next week so won't be able to land it yet. @ILyoan if you want to speed this along you might want to try rebasing 'wip' onto LLVM/compiler-rt trunk and try to get it building on linux/mac/windows. Since you have commit access you can test against the bots by pushing to mozilla's try branch. Then you can go to the buildbot's builders page and force builds of all the try branches. Note that to rebuild LLVM on the bots you need to set 'Property 1 Name' to clean-llvm and the value to 1. Also 'revision' needs to be the commit hash and (I think) 'branch' needs to be 'try'.

[sanxiyn]

There were two issues while upgrading to trunk:

• LLVMGetSectionName has an incompatible change.
• There was an ARM regression. Fixed now.

[ILyoan]

@brson Thanks for your help!!
We are preparing to send ARM morestack patch to upstream. I think we can send the path next week.
I'm expecting that there will be a couple of modifications to get ARM unwinding to work but I'm not sure if it is essential thing to be merged before 0.6.(At least I think it should be merged in 0.7 though)

[yichoi]

@brson depends on the progress of ARM unwinding. our priority is to enable debug information on ARM stack frame. I think ARM unwinding and ARM stack frame are same problem.
@ILyoan proceed ARM stack frame first, I will manage to handle rebase brson's tree with LLVM trunk

[yichoi]

@brson I am investigating your wip branch. Is compiler-rt necessary ? I am going to fork https://github.com/llvm-mirror/llvm not https://github.com/chapuni/llvm.

[brson]

I believe it is, though I don't know why.
On Mar 19, 2013 5:02 AM, "yichoi" notifications@github.com wrote:

@brson https://github.com/brson I am investigating your wiphttps://github.com/brson/llvm/tree/wipbranch. Is compiler-rt necessary ? I am going to fork
https://github.com/llvm-mirror/llvm not https://github.com/chapuni/llvm.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/5368#issuecomment-15110439
.

[yichoi]

@brson wip2 forked from Latest LLVM plus our ARM patch works without clang and compiler-rt. Latest Rust with LLVM wip2 maintained Here. All test passed on linux except debug-info. I think debugging format could be changed.

[brson]

I tried several different variations of branchs that pulled together all the necessary changes and ended up with this one here. It includes the __morestack changes to rust and the fix for the OS X metadata changes in LLVM. The only problem I'm seeing is that when building on x86_64-unknown-linux-gnu with --disable-optimize the stage1 build of librustc segfaults. I looked into it for a few hours but didn't solve anything.

[yichoi]

I was wrong. I misunderstood disable optimization as --disable-optimize-llvm then tried which was successful but --disable-optimize failed like you.
I tried with LLVM rebased with latest one. but also failed.