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
Chris Lattner
2014-Oct-21 04:11 UTC
[LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?
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 fromI think this is what Chandler is proposing to fix: every module will have a DataLayout string. -Chris
Robinson, Paul
2014-Oct-21 05:17 UTC
[LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?
> 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. > > -ChrisI 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
Eric Christopher
2014-Oct-21 05:41 UTC
[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
Seemingly Similar 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?