Re: [avr-llvm-devel] Regression tests

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

Thanks, I'm reviewing them now

El viernes, 15 de junio de 2012, Nicklas Bo Jensen escribió:

> Hi,
>
> Please review these tests.
>
> Any comments?
>
> On Wed, Jun 6, 2012 at 2:46 AM, Borja Ferrer <bor...@gm...>wrote:
>
> 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?
>
> Checkin
>
>