Robinson, Paul
2014-Oct-21 05:17 UTC
[LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Chris Lattner > On Oct 20, 2014, at 8:22 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Mon, Oct 20, 2014 at 7:51 PM, Chris Lattner <clattner at apple.com> > wrote: > >> Hi Eric, > >> > >> Can you elaborate on your goals and what problem you are trying to > solve? As Chandler points out, DataLayout is part of module for a reason. > > > > Which is an interesting point - it's not really. (This was also going > > to be part of my talk next week, but since it's been brought up...) > > > > So the storage for DataLayout right now is on a per-subtarget basis. > > I.e. if you don't construct one in the module the backend will make > > one up based on information in the subtarget (everything from > > I think this is what Chandler is proposing to fix: every module will have > a DataLayout string. > > -ChrisI am not sure exactly where Eric is headed, but I can imagine that it would be cool to be able to compile most functions for the CPU and some for the GPU out of the same Module. 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? I'm out of my depth technically here, but I feel compelled to raise the question even if it's only to address my own ignorance. I can't say necessarily whether my employer would care but I sure don't want to close out any intriguing options. --paulr
David Chisnall
2014-Oct-21 08:26 UTC
[LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?
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). David
Reid Kleckner
2014-Oct-21 17:12 UTC
[LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?
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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141021/4a96f3db/attachment.html>