<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 21, 2014 at 1:26 AM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 21 Oct 2014, at 06:17, Robinson, Paul <<a href="mailto:Paul_Robinson@playstation.sony.com">Paul_Robinson@playstation.sony.com</a>> wrote:<br>
<br>
> Attaching a single DataLayout to the Module<br>
> would seem to require that these guys both use the same DataLayout; is that<br>
> really how things work in the real world?<br>
<br>
</span>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).</blockquote><div><br></div><div>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.</div></div></div></div>