Re: [avr-llvm-devel] Regression tests

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Oh congrats with your new role at Atmel Eric, hope to see you around a bit
more when you get some spare time and get a fast recovery from that flu.

Ahh I see Nicklas, thats the reason, try patching it with the patches in
SVN (under the clang dir), it's important because there we add suport for
interrupts and PROGMEM syntax. But concerning this test case, the frontend
needs the datalyout of the AVR arch. Basically with that we define the
sizes of ints, longs, floats etc. Since you didn't do that clang is
defaulting the size of ints to 32bit data.
Another thing I've been thinking about the test, since we're testing
codegen stuff, this means llvm asm -> avr asm and not C code -> avr asm, at
the end the test would be something like:

   1. define i8 @add8(i8 %a, i8 %b) {
   2.         %result = add i8 %a, %b
   3.         ret i8 %result
   4. }

So we ignore all the alloca and load and store stuff that is generated by
clang and just concentrate on what we are interested, the add instruction.
It's nice to use clang to convert C code to llvm asm, but then it has to be
cleaned and leave only the things we are interested in.

2012/4/30 Nicklas Bo Jensen <nbj...@gm...>

> No, im using a completely standard version of clang.
>
>
> On Mon, Apr 30, 2012 at 9:01 PM, Borja Ferrer <bor...@gm...>wrote:
>
>> Nice to see you around Eric :)
>>
>> Indeed, things are getting zero extended and then truncated back, there
>> are two things going on here. First is that I'm getting things converted to
>> i16 instead of i32, did you patch clang? I'll have to check if the target
>> patch stuff of clang is right. Second is that I dont have the zeroext
>> attribute and that's my fault because it's a patch for clang that I haven't
>> commited.
>>
>> The type promotion is something in the C standard and because sizeof(int)
>> is bigger than a register things get a bit nasty, but it's valid code.
>>
>>
>> 2012/4/30 Nicklas Bo Jensen <nbj...@gm...>
>>
>>> I'm using clang.
>>>
>>> define zeroext i8 @add() nounwind uwtable {
>>>   %a = alloca i8, align 1
>>>   %b = alloca i8, align 1
>>>   store i8 5, i8* %a, align 1
>>>   store i8 7, i8* %b, align 1
>>>   %1 = load i8* %a, align 1
>>>   %2 = zext i8 %1 to i32
>>>   %3 = load i8* %b, align 1
>>>   %4 = zext i8 %3 to i32
>>>   %5 = add nsw i32 %2, %4
>>>   %6 = trunc i32 %5 to i8
>>>   ret i8 %6
>>> }
>>>
>>> On Mon, Apr 30, 2012 at 8:22 PM, Borja Ferrer <bor...@gm...>wrote:
>>>
>>>> I see what's going here, our version is doing a 16bit addition and then
>>>> truncating it back to 8bits. Are you using clang or dragonegg for the
>>>> frontend? And can you post the llvm asm?
>>>> Also, no need to test imm+imm, only reg+imm and reg+reg will do, the
>>>> other will be constant folded.
>>>>
>>>> Ah, you'll need svn commit access, John or Eric could you do it?
>>>>
>>>>
>>>> 2012/4/30 Nicklas Bo Jensen <nbj...@gm...>
>>>>
>>>>> On Mon, Apr 30, 2012 at 12:33 AM, Borja Ferrer <bor...@gm...>
>>>>>  wrote:
>>>>>
>>>>>> It should be similar to what other backends do, in this case we
>>>>>> should test adding with 2 regs and then with immediates values, and repeat
>>>>>> this for each value type (i8, i16, i32 and i64). Checking the instruction
>>>>>> itself is enough, no need to check for registers aswell, that will come in
>>>>>> other tests. But when testing with imm values we should check that the imm
>>>>>> value is correctly generated, so in this case ignore the reg, but check
>>>>>> that the imm field is valid.
>>>>>>
>>>>>
>>>>> Ok, makes sense. I will work on creating the tests.
>>>>>
>>>>>
>>>>>> And what do you mean in that you get different code between gcc and
>>>>>> llvm?
>>>>>
>>>>>
>>>>> Basically if I compile:
>>>>>
>>>>> unsigned char add()
>>>>> {
>>>>>   unsigned char a,b;
>>>>>   a = 5;
>>>>>   b = 7;
>>>>>   return a+b;
>>>>> }
>>>>>
>>>>>
>>>>> with avr-gcc part of the resulting assembler is:
>>>>> ldi r24,lo8(5)
>>>>>  std Y+1,r24
>>>>> ldi r24,lo8(7)
>>>>> std Y+2,r24
>>>>> ldd r25,Y+1
>>>>>  ldd r24,Y+2
>>>>> add r24,r25
>>>>>
>>>>> with clang+avr-llvm part of the resulting assembler is:
>>>>>  ldi r24, 5
>>>>> std Y+2, r24
>>>>> ldi r24, 7
>>>>>  std Y+1, r24
>>>>> ldd r24, Y+2
>>>>>  adiw r25:r24, 7
>>>>> andi r24, 255
>>>>>  andi r25, 0
>>>>>
>>>>> So they use different approaches(add and adiw) to solve the same
>>>>> problem.
>>>>>
>>>>> Thanks
>>>>> Nicklas
>>>>>
>>>>> 2012/4/29 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>
>>>>>>> Sure. Just wanted to actually compile the code before writing tests.
>>>>>>>
>>>>>>> Got how the test framework works and added a very small test that is
>>>>>>> working perfectly.
>>>>>>>
>>>>>>> How detailed should the test be? Should it check the generated
>>>>>>> assembly fully or just the main parts, e.g. the addition itself? For an
>>>>>>> addition the avr-llvm version is quite different from the avr-gcc version.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Nicklas
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Apr 29, 2012 at 8:07 PM, Borja Ferrer <bor...@gm...
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> The problem here is that I've represented register pairs as r29:r28
>>>>>>>> while the assembler only wants the low register of the pair, that's why
>>>>>>>> you're getting that error but you're doing it right.
>>>>>>>>
>>>>>>>> But the way of writing regression tests in llvm is different to
>>>>>>>> what you're doing. Those tests in SVN are going away once we start writing
>>>>>>>> the new ones.
>>>>>>>>
>>>>>>>> Read this: http://llvm.org/docs/TestingGuide.html
>>>>>>>> and then go to
>>>>>>>> http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/ and
>>>>>>>> choose any target you wish (say msp430 since it's the most similar one to
>>>>>>>> us) to see how real tests look like.
>>>>>>>>
>>>>>>>> Basically, you have to write a test in llvm assembly, and then with
>>>>>>>> CHECK you write the avr assembly that should be emitted, if it matches then
>>>>>>>> the test passes otherwise it fails. You can avoid writing the llvm assembly
>>>>>>>> by writing the test in C and then translate it to llvm assembly with clang.
>>>>>>>>
>>>>>>>> Try writing a small test for add using the llvm testing
>>>>>>>> infrastructure and then run it with llvm to see if it passes.
>>>>>>>> It's very important that you write the expected output assembly
>>>>>>>> right, otherwise we'll generate wrong code to make the test pass, but since
>>>>>>>> tests are quite small it's easy to get it right.
>>>>>>>>
>>>>>>>>
>>>>>>>> 2012/4/29 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I have successfully been able to compile your testcases
>>>>>>>>> (/avr-llvm/testcases/*.ll) to something looking like valid avr assembler.
>>>>>>>>>
>>>>>>>>> How should I test/simulate the assembler? I get errors when trying
>>>>>>>>> to simulate the generated assembler in AVRStudio. Perhaps they use a
>>>>>>>>> different assembler?
>>>>>>>>>
>>>>>>>>> For one test, add1.ll I cannot process it using avr-as. I have
>>>>>>>>> done:
>>>>>>>>>
>>>>>>>>> ../../build/Debug+Asserts/bin/llc --march=avr add1.ll -o add1.s
>>>>>>>>> avr-as -mmcu=atmega168 add1.s
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> and get the error:
>>>>>>>>>
>>>>>>>>> asm.s: Assembler messages:
>>>>>>>>> asm.s:12: Error: register r24, r26, r28 or r30 required
>>>>>>>>> asm.s:12: Error: `,' required
>>>>>>>>> asm.s:12: Error: garbage at end of line
>>>>>>>>> asm.s:24: Error: register r24, r26, r28 or r30 required
>>>>>>>>> asm.s:24: Error: `,' required
>>>>>>>>> asm.s:24: Error: garbage at end of line
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Am I doing something wrong? I have included the assembler.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Nicklas
>>>>>>>>>
>>>>>>>>> On Sun, Apr 29, 2012 at 7:23 PM, Borja Ferrer <
>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>
>>>>>>>>>> Hello Neil I'm replying you in this thread, i dont know why I
>>>>>>>>>> didn't receive your mail, i had to look in SF to read it.
>>>>>>>>>>
>>>>>>>>>> Anyways, first try to build the backend so you can play a bit
>>>>>>>>>> with it to get familiar with its code. Try compiling some C code to
>>>>>>>>>> generate avr assembly.
>>>>>>>>>>
>>>>>>>>>> 2012/4/23 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I'll be happy to contribute, after I have fixed my issues
>>>>>>>>>>> getting avr-llvm to compile in the first place.
>>>>>>>>>>>
>>>>>>>>>>> BR,
>>>>>>>>>>> Nicklas
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Apr 22, 2012 at 7:26 PM, Borja Ferrer <
>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I think it's time to stop adding more features until we cover
>>>>>>>>>>>> what is currently implemented with regression tests. Otherwise the further
>>>>>>>>>>>> we go the harder will be to cover everything up, from now on it's going to
>>>>>>>>>>>> be easier to go in parallel.
>>>>>>>>>>>> In the past emails I've seen people interested in helping out
>>>>>>>>>>>> with this, it's a good way of starting with some development becuase it's
>>>>>>>>>>>> an easy task to do and it helps to understand how llvm works, so anybody
>>>>>>>>>>>> interested check in here so I know if I'm going to have any help at all or
>>>>>>>>>>>> I have to do it myself.
>>>>>>>>>>>>
>>>>>>>>>>>> So if there's some help available we can plan in this thread
>>>>>>>>>>>> what needs to get covered and how to do it, I'll wait a few days for any
>>>>>>>>>>>> replies.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>> For Developers, A Lot Can Happen In A Second.
>>>>>>>>>>>> Boundary is the first to Know...and Tell You.
>>>>>>>>>>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>>>>>>>>>>>> http://p.sf.net/sfu/Boundary-d2dvs2
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> avr-llvm-devel mailing list
>>>>>>>>>>>> avr...@li...
>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> Live Security Virtual Conference
>>>>>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>>>>>> threat landscape has changed and how IT managers can respond.
>>>>>>>>>> Discussions
>>>>>>>>>> will include endpoint security, mobile security and the latest in
>>>>>>>>>> malware
>>>>>>>>>> threats.
>>>>>>>>>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> avr-llvm-devel mailing list
>>>>>>>>>> avr...@li...
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [avr-llvm-devel] Regression tests

This is the AVR port of LLVM.

Re: [avr-llvm-devel] Regression tests