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

[Duncan Exon Smith]

> On Oct 19, 2014, at 2:23 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> ----- 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
> 

Okay, cool.  I think I agree with you there. 

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