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

Hal Finkel hfinkel at anl.gov
Sun Oct 19 13:52:12 PDT 2014

----- Original Message -----

From: "Pete Cooper" <petercooper at apple.com> To: "Chandler Carruth" <chandlerc at gmail.com> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Sunday, October 19, 2014 3:34:59 PM Subject: Re: [LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?

Sent from my iPhone > On Oct 19, 2014, at 1:22 AM, Chandler Carruth <chandlerc at gmail.com> > wrote: > > I've just wasted a day chasing my tail because of subtleties > introduced to handle the optionality of the DataLayout. I would > like to never do this again. =] Agreed, it's a pain to do this. > > We now have this attached to the Module with just a flimsy faked-up > pass to keep APIs consistent. So, is there any problem with > beginning down the path of: > > 1) Synthesizing a "default" boring DataLayout for all modules that > don't specify one. > 2) Changing the APIs to make it clear that this can never be > missing and is always available. > 3) Start ripping out all of the complexity in the compiler dealing > with this. Sounds like a good plan. One more thing I'd like us to consider after this is where the struct layout map should live. Currently it's in DataLayout which feels right until you think that DataLayout lives in the module but is caching based on pointers in the context. It makes me feel like DataLayout should live in the context, but then LTO is an issue with linking modules with different layouts (is that even allowed?

I think that, generally speaking, this does not make sense. You could imagine linking together two modules where one data layout was a "subset" of the other (one is missing details of the vector types, for example, in a module that used no vector types), but even that seems tenuous.

-Hal

). I can think of a bunch of ways it could fail with struct layouts of the same struct on different DataLayouts.

Pete > > If there isn't, I'm willing to do some of the leg work here. > -Chandler _> ________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory

More information about the llvm-dev mailing list