It's not exactly simple to say either way.

For simple projects and not-too-complex code the IR technically can be cross-platform (although I never tried whether it worked between different endians); we got a number of early prototypes actually working. We compiled IR "object files" on x64 platform and managed to link them on ARM, after a few extra disassembly steps. They even ran. This was slightly more than 3 years ago.

However...

From my experience a more correct statement would be: "LLVM IR is mostly architecture independent." The moment you mix in extremely low-level code, such as atomics, portability of IR breaks down. The operations for atomic types are (or at least were) inlined as build-host assembly.

It was an interesting exercise nonetheless.

I find this surprising. The most common source of IR nonportability is from calling convention. Exactly same C function declaration would compile to different LLVM IR function declaration, and this has nothing to do with extremely low-level code.

For an example, look at http://llvm.org/devmtg/2014-10/Slides/Skip%20the%20FFI.pdf, from page 103 to 107.

Edit: There seems to be a misunderstanding. What I am saying is that "LLVM IR is mostly architecture indepedent" is false. LLVM IR is not even remotely architecture independent and nonportability happens with even the simplest codes.

From my (admittedly probably limited) experience with LLVM IR from writing my own compiler, it seems like if you were writing a program entirely in LLVM IR you could use a subset that could be compiled and run on any fully-supported LLVM target.

Of course that's a different proposition than e.g. compiling a C program to LLVM IR using Clang and then trying to compile that IR on a different target, or trying to interact with non-LLVM-IR functions that conform to the platform ABI.

Of course, the resulting native code may not be the best for the target, since e.g. a native integer on one platform might become a pair of smaller integers on another platform. But it could work.

With all of that said, I expect the proposal was to use the Rust compiler to compile the Rust compiler to IR, and I imagine Rust is complex enough that it must generate at least some target-specific IR. Perhaps one could take the generated IR and "normalize" it, but it's questionable whether it would be worth it.

rustc needs to interact with C ABI functions. To start, rustc needs to be able to call LLVM. As LLVM is not written in Rust, this is done with LLVM C API.

Well, at least with Qt (which declares its own assembly atomics at compile time) this was a real issue. When going through the disassembled bitcode files we saw that all calls to q_atomic types went through inlined platform-dependent assembly.

Of course anything compiled on x64 failed to link on ARM.

That seems contrary to what IR is supposed to do and how LLLVM was designed. Any links or explanations?

LLVM IR isn't supposed to be target independent in any way. It's an internal representation for a compiler backend- it has to be able to represent target-specific semantics at some point.

Think of LLVM IR more like a communications protocol between front-end and back-end. A defined abstraction so that the parts can be cleanly separated.