llvm dev - Oct 2007 - [LLVMdev] .ll test cases for tail call optimization in test-suite

On 12 Oct 2007, at 07:07, Evan Cheng wrote:
>>In order to test the tail call optimization i created quite a few
>>.ll files and added them to the SingleSource directory in the
>>test-suite.  For example
>>llvm-test/SingleSource/Tailcall/tailcall1-2.ll.
>Shouldn't these be dejagnu tests instead?
There is one test in dejagnu that tests whether tail call optimization
is performed when it should. And 2 tests that check handling of PIC.

But with dejagnu i would not test whether the resulting .s code when
compiled to an executable really runs. And with existing code in the
test suite generated from .c i would not know whether all the cases,
that i could make up, are covered.  This is why i moved them to the
test-suite.

I think greping for 'sub $esp val'/'add $esp val' usage would be
quite
fragile since the backend might decide to spill less/more registers.

While developing I used dejagnu for testing the .ll files but i
believe this is not how one is supposed to use the dejagnu tests (in
llvm/test)?

; RUN: llvm-as < %s | llc  -tailcallopt > %t1
; RUN: grep TAILCALL %t1
; RUN: gcc  -x assembler %t1
; RUN: ./a.out | grep -e {result: 11}

And in test-suite dejagnu tests are not supported right?

regards
arnold

On Oct 12, 2007, at 12:17 AM, Arnold Schwaighofer wrote:
> On 12 Oct 2007, at 07:07, Evan Cheng wrote:
>
>>> In order to test the tail call optimization i created quite a few
>>> .ll files and added them to the SingleSource directory in the
>>> test-suite.  For example
>>> llvm-test/SingleSource/Tailcall/tailcall1-2.ll.
>
>> Shouldn't these be dejagnu tests instead?
>
> There is one test in dejagnu that tests whether tail call optimization
> is performed when it should. And 2 tests that check handling of PIC.
Ok.
> But with dejagnu i would not test whether the resulting .s code when
> compiled to an executable really runs.
Right.
> And with existing code in the
> test suite generated from .c i would not know whether all the cases,
> that i could make up, are covered.  This is why i moved them to the
> test-suite.
>
> I think greping for 'sub $esp val'/'add $esp val' usage
would be quite
> fragile since the backend might decide to spill less/more registers.
We really don't want llvm/test to involve execution tests.  Is there  
any way you can make them grep for features that are intrinsic to the  
tail call?  How would grepping for stack adjustments be fragile?

-Chris