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

[Hal Finkel]

----- Original Message -----
> From: "Pete Cooper" <peter_cooper 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