[llvm-commits] [llvm] r67849 - /llvm/trunk/test/CodeGen/PowerPC/int-fp-conv-0.ll

[Chris Lattner]

On Mar 30, 2009, at 1:34 PM, Misha Brukman wrote:
>> Grepping through -debug output isn't very nice in any case, but at  
>> the
>> moment there aren't any better ways to express this specific test.
>>
>> You can write a unittest to check this.  It might require some  
>> refactoring to be able to run all of LLC's passes separately from  
>> running the tool on the command line, since they are currently hard- 
>> coded in its main() function.
>
> I don't think we want unit tests for passes.  We only want unit  
> tests for low level APIs.
>
> Let's drop the term "unit" and just call them tests.

Ok.

> I'm proposing we test passes in C++ instead of a shell script that  
> calls grep.

What is the real value of doing this?  The costs I see are 1)  
increased link time and 2) more dependence on the API (more to update  
when an API changes).

> How else can we check the correctness of a pass, which involves  
> pattern-matching multiple instructions?  Grep can only look at a  
> single line at a time, and doesn't have the semantic knowledge of  
> what's an instruction and what's an operand, whereas we have all  
> this information in C++.

I think the answer is that we need to build *one* small "llvmirgrep"  
tool that does this, which could be used by many different tests.

I don't know exactly the syntax for it, but I think it should be  
something like the tool we use in clang.  In clang, we write tests for  
diagnostics like this:

// RUN: clang-cc %s -verify -pedantic -fsyntax-only
void test4() {
       static int var;
       var =+ 5;  // expected-warning {{use of unary operator that may  
be intended as compound assignment (+=)}}
       var =- 5;  // expected-warning {{use of unary operator that may  
be intended as compound assignment (-=)}}
       var = +5;  // no warning when space between the = and +.
       var = -5;

       var =+5;  // no warning when the subexpr of the unary op has no  
space before it.
       var =-5;

#define FIVE 5
       var=-FIVE;  // no warning with macros.
       var=-FIVE;
}

In this case, the tool is built into clang, but it doesn't need to  
be.  The -verify mode basically runs the compiler as normal, but  
captures the generated diagnostics to a buffer.  It then scans the .c  
file for the "expected-" comments and "diffs" the generated and  
expected diagnostics.


If we had an llvmirgrep tool, then we could do something like this:

; RUN: llvm-as < %s | opt -instcombine | llvm-irgrep %s

define i32 @test(float %f) {
       ; irgrep {%t1 = bitcast float %f to i32}
       ; irgrep {ret i32 %t1}
         %tmp7 = insertelement <4 x float> undef, float %f, i32 0
         %tmp17 = bitcast <4 x float> %tmp7 to <4 x i32>
         %tmp19 = extractelement <4 x i32> %tmp17, i32 0
         ret i32 %tmp19
}

Which would be smart enough to require that those two instructions be  
in that basic block of that function, and it would do a fuzzy match to  
ignore the fact that the generated code names the first instruction  
"%tmp19".

This is based on test/Transforms/InstCombine/vec_extract_elt.ll, and  
is just a really hand wavy theoretical syntax just to get the idea  
across.

What do you think?

-Chris





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20090331/1eca2217/attachment.html>