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

[Robinson, Paul]

> 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.
> 
> -Chris

I 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