llvm dev - Oct 2014 - [LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?

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

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.

-Chris

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. :)

Go total agreement!

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141022/17a970f7/attachment.html>