[LLVMdev] LLVM IR is a compiler IR
Renato Golin
rengolin at systemcall.org
Wed Oct 5 01:17:30 PDT 2011
On 5 October 2011 01:19, Chris Lattner <clattner at apple.com> wrote:
> I'm not sure what you're getting at here. My email was not intended to say that I'm not interested in LLVM improving - quite the contrary. My email was to rebut Dan's implicit claim that PNaCL and using LLVM as a portable IR is never going to work. I'm arguing in the "opencl" and "pnacl" folks favor :)
Hi Chris,
Ok, I think I (now) get your drift. Let's restart the conversation, then. ;)
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.
--
cheers,
--renato
http://systemcall.org/
PS: I hope to have gotten it right this time, neither were meant as rants...
More information about the llvm-dev
mailing list