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

Eric Christopher echristo at gmail.com
Mon Oct 20 22:41:53 PDT 2014


On Mon, Oct 20, 2014 at 9:11 PM, Chris Lattner <clattner at apple.com> wrote:
>
> On Oct 20, 2014, at 8:22 PM, Eric Christopher <echristo at gmail.com> wrote:
>
>> On Mon, Oct 20, 2014 at 7:51 PM, Chris Lattner <clattner at apple.com> wrote:
>>> Hi Eric,
>>>
>>> Can you elaborate on your goals and what problem you are trying to solve?  As Chandler points out, DataLayout is part of module for a reason.
>>
>> Which is an interesting point - it's not really. (This was also going
>> to be part of my talk next week, but since it's been brought up...)
>>
>> So the storage for DataLayout right now is on a per-subtarget basis.
>> I.e. if you don't construct one in the module the backend will make
>> one up based on information in the subtarget (everything from
>
> I think this is what Chandler is proposing to fix: every module will have a DataLayout string.
>

Right. I was figuring there'd be some way of having the backend
specify it if there isn't one in the module IR - or a way of calling
into the backend to generate one up since memorizing all of the
possible target layouts for all of the targets would probably be a
pain. These bits would probably be off of the TargetMachine right now.
It'd make moving the DataLayout string onto the TargetMachine easier
later if we decide to do that.

-eric



More information about the llvm-dev mailing list