Re: [avr-llvm-devel] Regression tests

[Nicklas Bo J. <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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>