Eric Christopher
2014-Oct-20 21:20 UTC
[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
Chris Lattner
2014-Oct-21 02:51 UTC
[LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?
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
Eric Christopher
2014-Oct-21 03:22 UTC
[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
Reasonably Related Threads
- [LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?
- [LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?
- [LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?
- [LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?
- [LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?