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

Robinson, Paul Paul_Robinson at playstation.sony.com
Mon Oct 20 22:17:27 PDT 2014

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

More information about the llvm-dev mailing list