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 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
particular subtarget, abi, etc) though I've been pulling that apart so
that it's at least on a per TargetMachine basis so that you'll get one
based on ABI (because I don't really see the point in dealing with ABI
changes between functions at the moment, though it's possible) and OS
which isn't going to change between subtargets.

So, after I'm done we remove all of the subtarget dependencies from
the TargetMachine specific DataLayout and we can put it on the
TargetMachine. This would mean that it would be effectively module
wide.

So on to that Pie in the Sky idea:

Be able to compile, in a single module, code for multiple targets at
once. This would be in the idea of an accelerator in some way on the
chip so that you can store pre-compiled versions of code for different
gpus, etc (things with a different architecture) that can then be
dispatched to via grabbing it out of the object file and sending the
data over an I/O connection etc.

It's pie in the sky and not very important at the moment. Having it at
the module level at the moment isn't an issue at the moment, or even
for the forseeable future - and it won't be difficult to move off if
necessary later. Just that if we were going to store it some place
then the TargetMachine seemed to be the best place because that's how
the backend will construct one if it's not supplied anyhow.

-eric

>
> -Chris
>
>> On Oct 20, 2014, at 2:20 PM, Eric Christopher <echristo at
gmail.com> wrote:
>>
>>> On Mon, Oct 20, 2014 at 1:27 PM, Chandler Carruth <chandlerc at
google.com> wrote:
>>>
>>> On Mon, Oct 20, 2014 at 1:18 PM, Eric Christopher <echristo at
google.com>
>>> wrote:
>>>>
>>>> Agreed. The DataLayout should move (back) to the TargetMachine
and live
>>>> there (I'm doing that part right now). I don't
particularly want to put it
>>>> on the module because of (admittedly pie in the sky) plans of
being able to
>>>> compile a module with two target machines at the same time.
>>>
>>>
>>> Wait, what? The DataLayout can't live in the target machine
without upending
>>> the layering completely. Every part of the IR optimizer uses it...
>>
>> Ha. And yet currently some of them are dependent upon subtarget
>> features. I'm separating them out, but making them "ARM"
or "X86" or
>> what have you seems to be the best route.
>>
>> -eric
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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.

-Chris

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu] On
> Behalf Of Chris Lattner
> 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.
> 
> -Chris
I am not sure exactly where Eric is headed, but I can imagine that it would
be cool to be able to compile most functions for the CPU and some for the
GPU out of the same Module.  Attaching a single DataLayout to the Module
would seem to require that these guys both use the same DataLayout; is that
really how things work in the real world?  I'm out of my depth technically
here, but I feel compelled to raise the question even if it's only to
address my own ignorance.  I can't say necessarily whether my employer
would care but I sure don't want to close out any intriguing options.
--paulr

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