[LLVMdev] LLVM IR is a compiler IR

[David Sehr]

All,

I should have chimed in earlier, but have been working on two more
side-channel variants of this conversation.
At the beginning the PNaCl team was strongly pushing for trying to keep
platform ABI compatibility on all
platforms while taking one portable bitcode stream as input.  During the
discussions we've had over the past few
weeks it became obvious that that is simply not tractable, and we're trying
to work in a slightly different direction
that meets PNaCl's needs.

PNaCl needs to have one bitcode representation that can be lowered to
efficient ABIs on all target platforms.
We're not constrained to have to use the exact ABI that trusted code would
on each of the platforms, however.
For reasons of portability we've already eliminated long double support (or
made it equivalent to double if you prefer).
And we're currently proposing to use the platform ABIs, except that
structure arguments (including unions, bitfields, etc.)
are always passed in memory.  With this set of caveats we think we can meet
our objectives for at least x86-32,
x86-64, and ARM.  The remaining complexity is making byval usable on all
platforms so that we can have one representation.
Of course we'd like community input on the issues we've overlooked.

There are other issues of compatibility that still keep us awake at night,
of course, and I hope the next developers'
conference will give us the chance to wrangle with some of those.

David

On Tue, Oct 4, 2011 at 5:19 PM, Chris Lattner <clattner at apple.com> wrote:

> On Oct 4, 2011, at 4:42 PM, Renato Golin wrote:
> > On 5 October 2011 00:19, Chris Lattner <clattner at apple.com> wrote:
> >> 1. The native client folks trying to use LLVM IR as a portable
> representation that abstracts arbitrary C calling conventions.  This doesn't
> work because the frontend has to know the C calling conventions of the
> target.
> > (...)
> >> 2. The OpenCL folks trying to turn LLVM into a portable abstraction
> language by introducing endianness abstractions.  This is hard because C is
> inherently a non-portable language, and this is only scratching the surface
> of the issues.  To really fix this, OpenCL would have to be subset
> substantially, like the EFI C dialect.
> > (...)
> >> It sounds like you're picking a very specific definition of what a VM
> is.  LLVM certainly isn't a high level virtual machine like Java, but that's
> exactly the feature that makes it a practical target for C-family languages.
>  It isn't LLVM's fault that people want LLVM to magically solve all of C's
> portability problems.
> >
> > Chris,
> >
> > This is a very simplistic point of view, and TBH, I'm a bit shocked.
>
> I'm sorry, I didn't mean to be offensive.
>
> > JIT, "the native client folks", "the openCL folks" are showing how
> > powerful LLVM could be, if it was a bit more accommodating. Without
> > those troublesome folks, LLVM is just another compiler, like GCC, and
> > being completely blunt, it's no better.
>
> 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
> :)
>
> That said, I'm trying to also inject realism.  C is an inherently hostile
> language to try to get portability out of.
>
> > The infrastructure to add new passes is better, but the number and
> > quality of passes is not. It's way easier to create new back-ends, but
> > the existing number  and quality, again, no better. The "good code" is
> > suffering a diverse community, large codebase and company's interests,
> > which is not a good forecast for code quality. It's not just the IR
> > that has a lot of kludge, back-ends, front-ends, dwarf emitter,
> > exception handling, etc., although some nicer than GCC, it's not
> > complete nor accurate.
>
> I'm not sure what point you're trying to make here.  We all know that LLVM
> sucks, fortunately lots of people seem to be motivated to help make it
> better :)
>
> > If you want to bet on a "fun community" to drive LLVM, I don't think
> > you'll go too far. And if you want to discard the OpenCL, JIT and
> > NativeClient-style community, well, there won't be much of a community
> > to be any fun...
>
> I think that we're pretty strongly miscommunicating...
>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111004/8774bd9f/attachment.html>