[LLVMdev] Fw: Thinking about "whacky" backends

[Reid Kleckner]

On Wed, Jun 1, 2011 at 12:53 PM, Henry Mason <thefridgeowl at gmail.com> wrote:
> This is pretty much what's happening with Portable Native Client, right?
>
> http://www.chromium.org/nativeclient/pnacl
>
> See also the first presentation from the November LLVM meeting: http://llvm.org/devmtg/2010-11/

PNaCl fixes data layout to be just "portable enough" to cover x86,
ARM, and x86_64, IIUC.  The size of a pointer in PNaCl is always 32
bits, for example.  It would still be useful to be able to generate
target neutral bitcode that doesn't need a special runtime and can
interface with regular native libraries.

We've talked about this before, but just thinking about it a bit
further, here are some examples of features people have asked for to
help make their frontends more target-neutral:
- a pointer-sized integer type
- unions
- bitfields

My understanding is that these are rejected because the primary
consumers of the IR are the optimizers and the code generators.  They
don't want to have to deal with these extra features complicating the
IR.  They prefer to see bitcasts and logical operators over unions and
bitfields.

An alternative is to introduce these features, but add a target
lowering phase that strips them from the IR and replaces them with the
target-dependent equivalent.  The downside here is that it undermines
the "single IR" LLVM approach.  OTOH, it's a lot like running mem2reg
before doing optimizations.

Reid