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

Duncan P. N. Exon Smith dexonsmith at apple.com
Sun Oct 19 14:20:15 PDT 2014

On 2014 Oct 19, at 13:52, Hal Finkel <hfinkel at anl.gov> wrote:

----- Original Message ----- From: "Pete Cooper" <petercooper 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

More information about the llvm-dev mailing list