llvm dev - Nov 2011 - [LLVMdev] Contributing new backend to LLVM

Eli, 

  We can probably think of something like that, but diff on assembly output
is prone to false negatives and depends on the machine independent part of
the compiler... 
Maybe someone can suggest more elegant way to verify the basic
functionality?

Thanks.

Sergei Larin

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum.

-----Original Message-----
From: Eli Friedman [mailto:eli.friedman at gmail.com] 
Sent: Tuesday, November 01, 2011 2:12 PM
To: Sergei Larin
Cc: Tony Linthicum; llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Contributing new backend to LLVM

On Tue, Nov 1, 2011 at 12:01 PM, Sergei Larin <slarin at codeaurora.org>
wrote:
> Eli,
>
>  When you say "include tests" what exactly do you mean - ability
to run
> newly produced binary on newly supported target?
> Can you please elaborate?
Well, it would be nice to know that it can produce working binaries,
but no, you don't need to provide tests like that.  Just make sure
there are tests in test/CodeGen/ to check that the backend generates
the expected assembly code for simple cases.

-Eli

On Nov 1, 2011, at 12:16 PM, Sergei Larin wrote:
> Eli, 
> 
>  We can probably think of something like that, but diff on assembly output
> is prone to false negatives and depends on the machine independent part of
> the compiler... 
Please look at how all of the existing tests in test/CodeGen/<Target> work
before rejecting the suggestion.

-eric

On 11/01/2011 09:16 PM, Sergei Larin wrote:
> Eli, 
> 
>   We can probably think of something like that, but diff on assembly output
> is prone to false negatives and depends on the machine independent part of
> the compiler... 
> Maybe someone can suggest more elegant way to verify the basic
> functionality?
Maybe tests like test/CodeGen/X86/fast-isel-call.ll, fast-isel-mem.ll, etc.
i.e. very few LLVM IR instructions, each in its own function, and using
CHECK:/CHECK-NEXT

Best regards,
--Edwin

Thanks, Eric and Eli.  We will do that, and will add some tests to 
include with our submission.

We are also in the process of getting our simulator and C library (both 
proprietary) released under a new license so that folks can download 
them and actually run programs.  That's a couple of months away, though, 
and doesn't really help much for creating LLVM regression tests.  Still, 
it will make reproducing problems easier. :)

Tony


On 11/1/2011 2:22 PM, Eric Christopher wrote:
>
> On Nov 1, 2011, at 12:16 PM, Sergei Larin wrote:
>
>> Eli,
>>
>>   We can probably think of something like that, but diff on assembly
output
>> is prone to false negatives and depends on the machine independent part
of
>> the compiler...
>
> Please look at how all of the existing tests in test/CodeGen/<Target>
work
> before rejecting the suggestion.
>
> -eric
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum.

> Maybe tests like test/CodeGen/X86/fast-isel-call.ll, fast-isel-mem.ll, etc.
> i.e. very few LLVM IR instructions, each in its own function, and using
CHECK:/CHECK-NEXT
Another example are msp430 / systemz backends which contain some
"feature" tests.

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

Sorry if it sounded like I have questioned the need for these tests - rather
I am trying to gather as much info up-front as I can. 
Maybe that's why some sort of FAQ for backend submission (as Tony pointed)
is not such a bad idea :) 

Thanks everyone for quick responses. Point is taken.

Sergei Larin

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum.


-----Original Message-----
From: Eric Christopher [mailto:echristo at apple.com] 
Sent: Tuesday, November 01, 2011 2:22 PM
To: Sergei Larin
Cc: 'Eli Friedman'; llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Contributing new backend to LLVM


On Nov 1, 2011, at 12:16 PM, Sergei Larin wrote:
> Eli, 
> 
>  We can probably think of something like that, but diff on assembly output
> is prone to false negatives and depends on the machine independent part of
> the compiler... 
Please look at how all of the existing tests in test/CodeGen/<Target> work
before rejecting the suggestion.

-eric