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

[Rafael Espíndola]

On 22 October 2014 15:35, Eric Christopher <echristo at gmail.com> wrote:
>
>
> On Wed Oct 22 2014 at 12:33:53 PM Chris Lattner <clattner at apple.com> wrote:
>>
>> On Oct 20, 2014, at 10:41 PM, Eric Christopher <echristo at gmail.com> wrote:
>> >>> 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.
>>
>> I think I see what you’re saying: you’re saying that it doesn’t make sense
>> for each target to know the DL string *and* to require each frontend to know
>> the DL string for each target it supports.
>>
>> If that’s the problem you’re trying to solve, the approach I would take is
>> to have Clang (and other frontends) query the TargetMachine directly when it
>> is setting up the module.  This will give you the layering that you’re
>> looking for, and avoid duplicating the magic strings.
>>
>
> Yep. That's basically what I was suggesting. :)

That is

llvm.org/pr5030

and

llvm.org/pr20787

Cheers,
Rafael