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

[Duncan P. N. Exon Smith]

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

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