Re: [avr-llvm-devel] Regression tests

[Borja F. <bor...@gm...>]

Fixed in SVN, let me know any other issues. Thanks for reporting it!

2012/6/5 Borja Ferrer <bor...@gm...>

> Something has changed in llvm or maybe it never worked, can't remember,
> but I'm unable to pass arguments through an icall, I'm investigating for a
> fix. In the meantime you can disable that assertion until I come with a
> proper fix.
>
>
> 2012/6/4 Borja Ferrer <bor...@gm...>
>
>> I'll take a look to it shortly.
>>
>>
>> 2012/6/3 Nicklas Bo Jensen <nbj...@gm...>
>>
>>> Ok. Sure your explanations are really clear :) Thanks!
>>>
>>> I'm having some trouble testing icall, which i'm doing using a function
>>> pointer. I've attached a small C example, the corresponding cleaned up llvm
>>> code and the output of running llc on it. There is a failed assertion.
>>>
>>> Any thoughts?
>>>
>>> On Fri, Jun 1, 2012 at 7:04 PM, Borja Ferrer <bor...@gm...>wrote:
>>>
>>>> Just checking for the sub instructions that allocate and restore the
>>>> stack should be enough, also check that the allocated size is correct, the
>>>> rest of stuff can be omitted. I would also check the whole sequence
>>>> including the interrupt instructions in a single test, no need to do it
>>>> everywhere. When we get to test allocas we'll have to test for prologue and
>>>> epilogue code, which is very similar to the one you're seeing here.
>>>> About testing push and pops: no need to test that, it's part of the
>>>> prologue/epilogue of the function, so it's not related to calls, also, that
>>>> is handled by llvm so I wouldn't test that at all. Remember to test the
>>>> icall instruction, as far as I remember it needs to be tweaked because for
>>>> now it doesn't save the registers between calls like regular calls do.
>>>>
>>>> Ok, memory instructions, most of the instructions you see in that file
>>>> that end up with a "w" are pseudo instructions (excluding sbiw/adiw, movw
>>>> or other real ones that work with 16bit data) meaning that they dont get
>>>> into the final assembly since they don't exist in the instruction set. It's
>>>> a trick to make llvm think they're supported instructions that way, movws
>>>> and the real 16bit insts get generated, however these pseudo ops get
>>>> expanded into 8bit ops, that's why you wont never see those in the final
>>>> assembly, and if you ever see one then it's a bug. So if you do an and with
>>>> 16bit types, llvm selects the andw pseudo op, and a later pass expands it
>>>> into two real 8bit and insts that are supported by the avr inst set, dont'
>>>> know if this makes things clear.
>>>>
>>>>
>>>> 2012/5/31 Nicklas Bo Jensen <nbj...@gm...>
>>>>
>>>>> Checking for stack allocation and restore could be something like:
>>>>>
>>>>> ; CHECK: in [[REG1:r[0-9]+]], 61
>>>>> ; CHECK: in [[REG2:r[0-9]+]], 62
>>>>> ; CHECK: sbiw [[REG2]]:[[REG1]], 4
>>>>> ; CHECK: out 62, [[REG2]]
>>>>> ; CHECK: out 61, [[REG1]]
>>>>> ; ... other tests
>>>>> ; CHECK: in [[REG1:r[0-9]+]], 61
>>>>> ; CHECK: in [[REG2:r[0-9]+]], 62
>>>>> ; CHECK: subi [[REG1]], 254
>>>>> ; CHECK: sbci [[REG2]], 255
>>>>> ; CHECK: out 62, [[REG2]]
>>>>> ; CHECK: out 61, [[REG1]]
>>>>>
>>>>> Is it something like that you have in mind? Should disabling and
>>>>> enabling interupts (cli+writeback of SREG) also be tested?
>>>>>
>>>>> Checking for the push and pops is going to be very fragile I think.
>>>>>
>>>>> Other backends have less thorough tests, but a bit alike, e.g. MBlaze
>>>>> in test/CodeGen/MBlaze/cc.ll. Here they do tests that registers are passed
>>>>> and returned in the correct registers or passed on the stack if needed.
>>>>>
>>>>> I've come quite far with memory operations, and have noticed the
>>>>> operations stsw and lddw in AVRInstrInfo.td, however I cannot find these in
>>>>> the Atmel AVR Instruction Set and cannot make llvm generate them. Could you
>>>>> give me a hint to why this is?
>>>>>
>>>>> On Thu, May 31, 2012 at 1:24 PM, Borja Ferrer <bor...@gm...>wrote:
>>>>>
>>>>>> They look very good. Yes, the order of loads is an issue, I don't
>>>>>> know how fragile this can get in case there are future changes that could
>>>>>> alter the order. Also it could be nice to check for stack allocation and
>>>>>> restore, have you checked if it's possible to do it? Add a TODO in the file
>>>>>> for args and for calls for testing for structs, this is something
>>>>>> unimplemented that needs to gets covered, I don't know yet any conventions
>>>>>> for those.
>>>>>>
>>>>>> One last thing, what do other backends do to cover these tests?
>>>>>> Anything similar to what we do?
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2012/5/30 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>
>>>>>>> Thanks for your explanation, it's clear.
>>>>>>>
>>>>>>> After a few days on holiday, I've worked on testing the calling part
>>>>>>> of the calling convention. Please see the attached file.
>>>>>>>
>>>>>>> I'm testing only passing parameters in the registers and on the
>>>>>>> stack. I'ts a bit hard to test in a good way, as for example the order of
>>>>>>> loads might be different, breaking the tests without having invalid code.
>>>>>>> I've tried to only tests the essentials in each case. Any comments or ideas
>>>>>>> for further tests?
>>>>>>>
>>>>>>>
>>>>>>> On Sat, May 26, 2012 at 6:28 PM, Borja Ferrer <bor...@gm...
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> About point 2:
>>>>>>>> As the calling convention states, arguments that don't fit in
>>>>>>>> registers r25 down to r8 are passed through the stack, that's why the last
>>>>>>>> argument is being passed this way. If registers Y or Z are used depends on
>>>>>>>> a number of conditions that are bit hard to explain, it depends if there
>>>>>>>> are spilled registers, allocas, and incoming arguments in the stack. In
>>>>>>>> this particular case, Y is ALWAYS used when reading incoming arguments from
>>>>>>>> the stack, Z COULD be used only when passing arguments into a function
>>>>>>>> call. So the difference is that Y is always used to READ incoming arguments
>>>>>>>> from the stack, and Z or Y can be used to WRITE arguments on the stack as
>>>>>>>> the preparation of the function call.
>>>>>>>>
>>>>>>>> About the code you attached I find it's correct. It's a void
>>>>>>>> function so why care on computing an add instruction where its result is
>>>>>>>> unused, also the return value of the called function is unused as well
>>>>>>>> since the add instruction is useless. That's why you see r25:r24 being
>>>>>>>> overwritten by the stack pointer so it can be restored to its original
>>>>>>>> state when the function ends.
>>>>>>>> This is all a bit tricky so if you dont understand feel free to
>>>>>>>> ask, it's important to get it right so you can write good tests.
>>>>>>>>
>>>>>>>> 2012/5/25 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>
>>>>>>>>> 1) The i8 @return8_reg test is fully commented out, can it be
>>>>>>>>>> removed? I don't understand what you want to test here.
>>>>>>>>>>
>>>>>>>>> Can be removed, was not supposed to be there :)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 2) In return64_arg2 the backend will always use Y to read
>>>>>>>>>> arguments from the stack, so there's no need to check for Z.
>>>>>>>>>>
>>>>>>>>> Ah ok, is there any rule for putting them on the stack? Here it
>>>>>>>>> can be both Y and Z right?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> About your calling tests, I can't see them xD
>>>>>>>>>
>>>>>>>>> Attached :)
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>