[LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?

[Eric Christopher]

On Tue, Oct 21, 2014 at 10:12 AM, Reid Kleckner <rnk at google.com> wrote:
> On Tue, Oct 21, 2014 at 1:26 AM, David Chisnall
> <David.Chisnall at cl.cam.ac.uk> wrote:
>>
>> On 21 Oct 2014, at 06:17, Robinson, Paul
>> <Paul_Robinson at playstation.sony.com> wrote:
>>
>> > Attaching a single DataLayout to the Module
>> > would seem to require that these guys both use the same DataLayout; is
>> > that
>> > really how things work in the real world?
>>
>> Yes and no.  In the general case, no.  In the specific case where you want
>> to do this kind of outlining, more or less.  At least, you want to make sure
>> that they use the same struct layouts and pointer sizes because, to get any
>> benefit from the accelerator, you don't want to have to do complex
>> operations when handing data off to it (and you do want it to be able to
>> access your memory directly).  In these cases, you want to ignore any ABI
>> that the accelerator might have 'natively' and force it to use the host's
>> data layout (although its own internal calling conventions, but that's not
>> part of the data layout.  Unfortunately, it *is* something that we don't
>> sanely abstract in the IR, which makes this kind of thing difficult).
>
>
> I think when doing this kind of accelerator stuff, it makes sense to always
> use packed structs. Then you don't need to worry about LLVM's data layout,
> you just always have something explicit that means the same thing to the
> accelerator and the host.

*nod* I'm mostly thinking about calling conventions and data types not
supported by the host (half float, etc). I'm not even worried about
each thing calling the other, just having precompiled things sit in
the binary.

-eric