[LLVMdev] Test Suite - Livermore Loops

[Renato Golin]

Forgot to mention, commenting out the line that runs opt with link time
opts solves the problem! ;)


On 3 January 2013 15:08, Renato Golin <renato.golin at linaro.org> wrote:

> FYI, attached is a way to reproduce the error without the
> test-suite paraphernalia.
>
> cheers,
> --renato
>
>
> On 3 January 2013 12:05, Renato Golin <renato.golin at linaro.org> wrote:
>
>> David,
>>
>> I got some more work on the Livermore Loops and I found out that the
>> issue is the difference in the parameters between a single step and a multi
>> step compilation.
>>
>> When you compile "clang kernel06.c" it works fine, but when you get all
>> steps (clang -emit-llvm + llvm-as + opt + llc etc), the defaults options of
>> each and how they interact is showing a bug in the code generated.
>>
>> This difference is due to the fact that I'm running the test-suite using
>> LNT, while the build bots are running it using Make directly. I'd expect
>> them both to be the same, but apparently they're quite different in what
>> kind of parameters they use, passes they test and results they get.
>>
>> I think there are two courses of action here:
>>
>> 1. Identify the issue, isolate the case and create a bug to resolve later.
>> 2. Make sure LNT does exactly what the build bots are doing
>>
>> I'm working on item 1 right now, not sure how item 2 can be solved...
>>
>> Of course, the fact that it's the not same flow meant we caught a bug in
>> LLVM, but that's bound to create more confusion and broken commits, which
>> is worse in the long run.
>>
>> Also, if we're not running LNT as often as buildbots, the benefit of
>> having them different is sporadic at best.
>>
>> When I set up some tests to run on ARM I have done both direct and
>> multi-step, to make sure they were generating the same code and in many
>> cases I found that the order in which the passes were executed was breaking
>> some tests.
>>
>> We managed to get the EDG bridge to set it up in the same way as the
>> multi-pass would, so we would get similar results, but it doesn't seem to
>> be the case with clang.
>>
>> cheers,
>> --renato
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130103/3f628525/attachment.html>