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

[Pete Cooper]

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