Hal Finkel
2014-Oct-19 20:52 UTC
[LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?
----- 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
Duncan P. N. Exon Smith
2014-Oct-19 21:20 UTC
[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. 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
2014-Oct-19 21:23 UTC
[LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?
----- 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
Joerg Sonnenberger
2014-Oct-20 10:13 UTC
[LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?
On Sun, Oct 19, 2014 at 03:52:12PM -0500, Hal Finkel wrote:> 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.I think linking modules with different vector types makes perfect sense. Consider a larger program that includes optimised SSE2 vs AVX routines, switching between them at run time. Joerg
Hal Finkel
2014-Oct-20 15:51 UTC
[LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?
----- Original Message -----> From: "Joerg Sonnenberger" <joerg at britannica.bec.de> > To: llvmdev at cs.uiuc.edu > Sent: Monday, October 20, 2014 5:13:03 AM > Subject: Re: [LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout? > > On Sun, Oct 19, 2014 at 03:52:12PM -0500, Hal Finkel wrote: > > 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. > > I think linking modules with different vector types makes perfect > sense. > Consider a larger program that includes optimised SSE2 vs AVX > routines, > switching between them at run time.Yes, we certainly want to support that. But even in that case, we'd use the same DataLayout for both modules (just specify different target cpus for the functions in the different modules). -Hal> > Joerg > _______________________________________________ > 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
Chris Lattner
2014-Oct-20 16:50 UTC
[LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?
On Oct 19, 2014, at 2:20 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:>>> 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.I agree. LLVMContext is about threading, not about datalayout. It is perfectly reasonable to use the same LLVM Context to hold IR for two different LLVM modules with different datalayout strings. -Chris