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