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
Chris Lattner
2014-Oct-22 19:33 UTC
[LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?
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
Eric Christopher
2014-Oct-22 19:35 UTC
[LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?
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>
Possibly Parallel 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?