[LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?
Hal Finkel
hfinkel at anl.gov
Sun Oct 19 14:23:42 PDT 2014
----- 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
More information about the llvm-dev
mailing list