[LLVMdev] make DataLayout a mandatory part of Module

[Nick Lewycky]

On 30 January 2014 02:10, 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?


There's two issues here. One is what to do if we encounter a .ll/.bc with
no target data. We're obliged to support llvm 3.0 bitcode files, so we need
to have an answer to this question.

Second is what to do in our test suite. If the answer to the first question
is "make it use the host target data" then the second part is a choice
either to leave the tests with no explicit layout and thereby use the host
target, or to require that tests in the testsuite specify their datalayout.
The tradeoff is that in one case we get more coverage across different
machines, and in the other case we get better reproducibility, which is
important for a regression suite or for a new user to verify that their
build of llvm is valid.

 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.
>

Exactly. As long as it's easy to grab the target datalayout from a
buildbot, we can slap it into our .ll file and reproduce the failure.

I can see both sides, and I know my preference, but I'd like to form
consensus.

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140131/bdbda942/attachment.html>