[LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout? (original) (raw)
Chris Lattner clattner at apple.com
Mon Oct 20 09:50:25 PDT 2014
- Previous message: [LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?
- Next message: [LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?
- Next message: [LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]