Is anyone working on supporting the newest LLVM version?

[shepmaster]

As part of the AVR-Rust project, I’m tracking the newest version of AVR-LLVM. Since that fork of LLVM is being merged into LLVM master, that means I’m attempting to compile Rust against LLVM master.

As might be expected, there are ongoing changes. A brief list:

• a method called LLVMBuildAtomicCmpXchg has been added, shadowing our local function.
• createInternalizePass doesn’t take arguments anymore
• more types need to be explicitly namespaced with llvm::legacy::
• PositionIndependentExecutable moved from targets to modules
• Debug metadata flipped the direction of the graph, making Rust produce invalid LLVM IR.

I have local fixes for all but the last point, but that one might be annoying to deal with. However, I’d love to collaborate with anyone who is also attempting to help Rust track LLVM 3.9-ish.

[proc]

createInternalizePass doesn’t take arguments anymore

is marked as link but points nowhere, is this intended ?

[shepmaster]

Ah, thank you, fixed now. Obviously you should be able to create a link with just a git hash and the browser will know where to go.

[brson]

@shepmaster I’m planning on porting rust forward to a newer version of llvm soon, but only up to the merge-base between upstream llvm and emscripten’s fastcomp/incoming llvm fork. This would at least get the llvm build converted to cmake.

[shepmaster]

get the llvm build converted to cmake.

That’s actually been quite easy as I’ve been using rustbuild, which only supports the CMake version.

[shepmaster]

For whoever is interested, I’ve at least code code compiling again. The trick to get the DebugInfo stuff to work again was to create the compile unit as soon as possible. This allows the debug builder to automatically link stuff up to it. The code is terrible and hacky, but I think the concept is sound.

[brson]

@shepmaster Rust has converted to building LLVM with CMake so the path is open to upgrade LLVM now. I’m not sure what @alexcrichton’s immediate plans are, but for the emscripten port we need to synchronize the Rust and emscripten forks. Right now what I’m anticipating is that we rebase onto LLVM master, and then emscripten does the same. How will that work out for your AVR port? I’m imagining that adding AVR support is going to end up requiring multiple LLVM upgrades over time, but we want to impose the least amount of pain on emscripten as possible. How do you see AVR integration proceeding?

[alexcrichton]

Ah I don’t personally have any immediate plans beyond “let’s upgrade LLVM at some point”. I’ve been told that this MIR blocking issue will be fixed with an LLVM upgrade, so I just wanted to make sure we could actually upgrade LLVM.

[shepmaster]

Right now what I’m anticipating is that we rebase onto LLVM master, and then emscripten does the same. How will that work out for your AVR port?

In general, that sounds reasonable. The AVR LLVM fork is merging into LLVM upstream and keeping reasonably up-to-date with master. As I mentioned before, I’ve been using the rustbuild system, which has supported the CMake build method from my initial use.

My main pain points center around the Rust integration with LLVM. You can see my commits that hack up Rust to support the LLVM 3.9 differences in the commit log tagged with [LLVM-3.9]. I hope that those provide a good start for someone who knows how to fix the issues in a more correct manner.

I’m imagining that adding AVR support is going to end up requiring multiple LLVM upgrades over time, but we want to impose the least amount of pain on emscripten as possible. How do you see AVR integration proceeding?

I also expect that AVR proper will take a while to get merged into LLVM, and I don’t expect the Rust fork of LLVM to continuously update to follow, especially if there are Rust-Emscripten-specific patches.

For the short term, it seems reasonable to build a completely separate compiler if you wish to target AVR. That compiler would use stock LLVM + AVR patches. Once AVR is fully landed in LLVM proper, then Rust should update LLVM again to include those changes.

[alexcrichton]

We’ve now upgraded to LLVM 3.9 (or what will eventually become LLVM 3.9)

[alevy]

I’m not sure if this belongs here or perhaps in a different thread, but…

LLVM recently (early August) landed a patch that adds support for two PIC strategies that are important to bare-metal on ARM – RWPI and ROPI. While the patches are in master, they have not yet landed in a released version, however, making these PIC strategies available to rustc (eventually) would be a huge benefit to those of us doing embedded development on ARM.

The high-level summary of this patch is that it allows the GOT to be resolved from a reserved register (r9 by default) rather than from a fixed location or one encoded in the code segments. In turn, this means that the code and data segments can be located not-relative to each other, without knowing their locations ahead of time, and without rewriting the code segment and load time (which is important when code is in read-only(ish) flash). It’s equivilant (and I believe compatible) to -msingle-pic-base in GCC.

I would love to help push forward getting this into Rust.

What are the (non-technical) requirements to upgrade LLVM versions? It sounds like there needs to be emscripten support. Is it important for the upgrade to be based on a currently released version?

Conversely, is there a process in place for upgrading LLVM “eventually”, or is done ad-hoc, when there are useful features? If the latter, is there any interest in putting in a process to keep LLVM up to date?

[brson]

What are the (non-technical) requirements to upgrade LLVM versions? It sounds like there needs to be emscripten support. Is it important for the upgrade to be based on a currently released version?

Conversely, is there a process in place for upgrading LLVM “eventually”, or is done ad-hoc, when there are useful features? If the latter, is there any interest in putting in a process to keep LLVM up to date?

@alevy To get an update done one has to be motivated to do it, and convince @alexcrichton at least that its worth the effort since he’s usually the one dealing with all the fallout across the bots.

Since we’re now trying to stay in sync with emscripten the way this will probably work is to do the Rust upgrade; test it on the dev machines against as many architectures as we can to be sure we’ve identified a viable commit; ask @kripken to prepare an emscripten upgrade; land the rust upgrade; land the emscripten upgrade. We want the window during which rust and emscripten are on mismatched LLVMs to be as small as possible.

It is not important for either the rust or emscripten LLVM to be based on a released LLVM, though it is important for rust to optionally support some released LLVM.

There is no defined process for upgrading LLVM - we do it when the motivation becomes great enough. I don’t think there’s been much demand for a more-defined process for updating LLVM but if you have some ideas about it perhaps you can say more.

[shepmaster]

FWIW, the AVR project has started tracking LLVM 4.0, so we might be pushing up a few related commits to allow Rust to target that branch soon. Working on laying some groundwork to start with.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.