[LLVMdev] LLVM IR is a compiler IR

[azakai]

Renato Golin <rengolin <at> systemcall.org> writes:
> 
> If I got it right this time, from your point of view, Dan's arguments
> are not accurate because IR never intended to be anything else anyway.
> PNaCl, OpenCL, RenderScript, Java-like VMs were aggregated over time
> and tried to use IR for what it was not designed to be. I completely
> agree with you in that one.
> 
> If I'm not mistaken, JIT was never intended to be portable, but to
> test IR during a time back-ends were not stable enough. IR was never
> intended to cover ABI issues, complex type system, endianness of the
> read/write, etc. In effect, IR was never intended to be completely
> language/target agnostic. Again, I completely agree on that one.
> 
> But there is a subliminal context that I don't think people
> understand, and that was my point.
> 
> Communities are powerful things. It takes a while to create, but once
> you have it, it has a life of its own. For the community, it doesn't
> matter much what were the original goals of LLVM, just what you can do
> with it, now. LLVM is the *only* compilation infrastructure I know
> that is flexible and extensible enough to allow people to do such
> radical things in radically different ways.
> 
> In a nutshell, Chris, you are a victim of your own success. If LLVM
> wasn't that flexible, people wouldn't stretch it that much, and you
> wouldn't have those problems.
> 
> LLVM's community is strong, active and passionate. But OpenCL folks
> will be passionate about adding OpenCL features, and so on and that
> creates tension (and I understand the defensive position you have
> always been, protecting LLVM's integrity).
> 
> But if you read in between the lines of what people are saying (and
> what I heard over and over during the Euro-LLVM), people are skeptical
> of the portability issue. Almost everyone, including experienced
> compiler engineers, comes to LLVM thinking the IR is portable. So,
> either we're all doing the wrong advertising of what LLVM really is,
> or we're not doing our jobs right.
> 
> I'm now reading David Sehr's answer (and John's reply) and I think
> we're still missing the point. David listed the hacks he had to do to
> make it somewhat portable. I've listed (mostly last year) the hacks we
> had to do to implement the EDG bridge. Talin keeps reminding us what
> he has to do to work on his compiler. James wrote his own bytecode
> language on top of IR.
> 
> If LLVM IR is not portable, and never will be, that's fine. I can live
> with that. But ignoring the crowd is not wise. I'm not saying you guys
> should implement a higher-level IR or change the current IR to fit to
> everyone's needs, that would be madness. What I'm asking is simply
> that you stop ignoring the fact that there is a problem (that lots of
> people want more portable IR) and that the solution is NOT to kludge
> it into the current IR.
> 
> When people show hacks, don't say "excellent! problem solved". When
> people ask for portability solutions, don't recommend kludges, or "do
> like clang". Encourage people to contribute to portability, and be
> willing to accept such contributions even if that generates a bit more
> work to get it through than a kludge.
> 

I thought I'd offer the perspective from another project
that uses LLVM and needs to be cross platform, Emscripten.
Emscripten takes LLVM assembly and compiles that into JavaScript.
We have had to implement a lot of hacks to work around
portability issues in LLVM assembly, but overall *un*-optimized
assembly is not that hard to get working. Optimized assembly
is a different story, but since the target language is JS
that isn't too much of a concern (we can do standard compiler
optimizations after translation to JS, using Closure Compiler
and other tools, with good results - since it is then done
at the level of JS).

Overall LLVM has been extremely useful for Emscripten
because it is very well documented and developed and has
a friendly community.

If LLVM assembly could be portable (no hardcoded structure
indexes, no hardcoded sizes, etc. etc.) then that would be
much better for Emscripten obviously. But I think that
even without that, LLVM assembly is already very usable
for some types of projects that require portability. So,
given how difficult portability is to get right, and that it
typically requires compromises elsewhere, my recommendation
would be to consider such things very carefully. I'd love
for there to be some way to generate portable assembly, but
I am not sure LLVM should try to do that - it does other
things, and it does them extremely well.

- azakai