[LLVMdev] RFC: Are we ready to completely move away from the optionality of a DataLayout?

[Eric Christopher]

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>