[LLVMdev] make DataLayout a mandatory part of Module

[Jeremy Lakeman]

In a very general sense, I would recommend this approach.

Push all of the existing "No datalayout" behaviour decisions into a default
data layout. Keep the behaviour, but tidy up the API.

While LLVM is not designed to be a target independent IR, particularly for
compiling C. Some other frontend languages may wish to use it that way.


On Fri, Jan 31, 2014 at 1:54 AM, Matt Arsenault <arsenm2 at gmail.com> wrote:

>
> On Jan 30, 2014, at 2:10 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk>
> wrote:
>
> > On 30 Jan 2014, at 00:04, Nick Lewycky <nlewycky at google.com> wrote:
> >
> >> This is also what many clang tests do, where TUs get parsed using the
> host triple. If we keep target datalayout out of the test files and fill it
> in with the host's information, then our test coverage expands as our
> buildbot diversity grows, which is a neat property.
> >
> > Unfortunately, reproducibility suffers.  You commit a change, a test
> fails on two buildbots but passes on all of the others and on your local
> system.  Now what do you do?  I've already hit this problem in clang, with
> host-defined tool search paths leaking into the tests and causing them to
> fail on Windows only.  It's hard to fix a bug that causes a buildbot
> failure if you can't reproduce it.  At the very least, the target / data
> layout should be in the failure message that the test suite generates in
> case of failure so that you can reproduce it locally if a buildbot reports
> failure.
> >
> > David
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> Why not default to using a generic datalayout that just uses the defaults
> for everything?. There are already defaults, since not every option needs
> to be specified in it, you just don't get them when you don't have one at
> all. Some places without one already make some assumptions like that.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140131/92eeb6ed/attachment.html>