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>
Rafael Espíndola
2014-Oct-22 19:51 UTC
[LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?
On 22 October 2014 15:35, Eric Christopher <echristo at gmail.com> wrote:> > > 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. :)That is llvm.org/pr5030 and llvm.org/pr20787 Cheers, Rafael
Eric Christopher
2014-Oct-22 22:15 UTC
[LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?
Yep. Thanks for the reference though :) -eric On Wed Oct 22 2014 at 12:51:16 PM Rafael Espíndola < rafael.espindola at gmail.com> wrote:> On 22 October 2014 15:35, Eric Christopher <echristo at gmail.com> wrote: > > > > > > 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. :) > > That is > > llvm.org/pr5030 > > and > > llvm.org/pr20787 > > Cheers, > Rafael >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141022/6c85cc14/attachment.html>