[PATCH] Make DataLayout Non-Optional in the Module

[Eric Christopher]

On Mon, Mar 2, 2015 at 10:25 AM Mehdi Amini <mehdi.amini at apple.com> wrote:

>
> > On Mar 2, 2015, at 9:40 AM, Eric Christopher <echristo at gmail.com> wrote:
> >
> > Few small comments:
> >
> > a) You've got Function::getDataLayout - I think I'd prefer people to
> generally have to ask the Function parent to get the data layout. (It's
> also a little inconsistent in the code, but should be fairly sed'able).
>
> Not sure I understand what you mean. Are you saying that getDataLayout()
> should be available on the module only?
> Note: I haven’t added this, there is a getDataLayout() in Instruction,
> BasicBlock, and GlobalValue.
> It saves some space when the only thing you have is an instruction:
>    I->getParent()->getParent()->getParent()->getDataLayout();
>
>
>
Oh, I don't particularly care (though Instruction and BasicBlock seem
weird), just that it wasn't consistent in the patch, but I can't say
anything about that either.


> > b) Routines to construct a data layout (Totally a follow up patch) in
> llvm rather than requiring each front end to handle construct them up
> themselves.
> >
> > c) Relatedly you don't do anything about the code in the backends that
> constructs the data layouts?
>
> I haven’t touch the backend yet, I plan on reworking this when I’m done
> with the IR-level.
>
>
OK.

-eric


> —
> Mehdi
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150302/5f637bf4/attachment.html>