[LLVMdev] Fw: Fw: Thinking about "whacky" backends

[Samuel Crow]

Once again, forgot to CC the list.


----- Forwarded Message -----
> From: Samuel Crow <samuraileumas at yahoo.com>
> To: Reid Kleckner <reid.kleckner at gmail.com>
> Cc: 
> Sent: Wednesday, June 1, 2011 2:03 PM
> Subject: Re: [LLVMdev] Fw: Thinking about "whacky" backends
> 
> 
> 
> 
> 
> ----- Original Message -----
>>  From: Reid Kleckner <reid.kleckner at gmail.com>
>>  To: Henry Mason <thefridgeowl at gmail.com>
>>  Cc: Samuel Crow <samuraileumas at yahoo.com>; LLVM Developers Mailing 
> List <llvmdev at cs.uiuc.edu>
>>  Sent: Wednesday, June 1, 2011 12:18 PM
>>  Subject: Re: [LLVMdev] Fw: Thinking about "whacky" backends
>> 
>>  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.
> 
> Hello Reid,
> 
> 
> I think the pointer-sized integer was replaced by allowing pointer arithmetic.
> 
> My approach would be to have a late-binding bitcode file that would link-in at 
> install time.  It could contain functions to do some of those tasks.  Bitfields 
> are just shifts and masks, after all.
> 
> Talan tried to add unions and failed.
> 
> I'm not sure I appreciate the target lowering phase idea.  I think it would 
> be more useful just to not use alignment specific functions in reads and writes 
> of files and packets.  They could be placed in the wrapper along with the LibC 
> bindings when needed for networking.  If the program needs to save something in 
> a system-independent fashion, it could use a fixed version of the bitcode writer 
> or something using externally defined types like StdInt.h for example.
> 
> Thanks for discussing with me,
> 
> --Sam
>