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

[Hal Finkel]

----- Original Message -----
> From: "Duncan P. N. Exon Smith" <dexonsmith at apple.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Pete Cooper" <peter_cooper at apple.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Sent: Sunday, October 19, 2014 4:20:15 PM
> Subject: Re: [LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?
> 
> 
> > On 2014 Oct 19, at 13:52, Hal Finkel <hfinkel at anl.gov> wrote:
> > 
> > ----- 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.
> > 
> 
> If you're suggesting that a given context should only support modules
> with a single common data layout, that doesn't make sense to me.

Me either. I was simply saying that linking them together likely does not make sense.

 -Hal

> 
> Even if we don't want to support *linking* modules with different
> data
> layouts, why wouldn't we support loading them both from bitcode in
> the
> same context?  Seems like an awkward limitation.
> 
> Is this a concern over memory usage, when there are multiple modules
> with the same data layout?  If so, could that be solved by uniquing
> in the context?
> 
> > -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
> > _______________________________________________
> > 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