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 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

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.

-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 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