Re: [avr-llvm-devel] Important stuff

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

During the past few days i've been investigating how to do this, i'm playing
with the register file description and custom lowering. What i thought is to
always use register pairs, split them to perform the 8 bit operation and
join them again for the next operation, of course this is for data wider
than 8bits.
Right now i'm getting promising results, but still needs improvement, llvm
is using a new register when splitting the pair instead of using the same
subreg. I'll continue investigating, and post any results, we really need to
get this clear before advancing into more complex operations like memory
stuff and branching.

2010/11/19 Borja Ferrer <bor...@gm...>

> We need to figure out some important things that need to be introduced in
> the compiler before we advance with bigger things. The things i'm talking
> about are:
>
> 1) aligning data wider than 1 byte in even registers to favour movws and
> argument passing into functions.
>  int16 a = b; // a = r21:r20, b = r13:r12
>  movw r20, r12 <--- good reg allocation
>
>  int16 a = b; // a = r20:r21, b = r12:r13
>  mov r21, r13
>  mov r20, r12 <--- bad reg allocation
>
> 2) THE BIG ONE: working with register pairs. there are some instructions
> like sbiw/adiw, movw, ld/st that only work with register pairs. we need to
> figure out how to introduce them.
> For example, I wrote a pass that converts 2 moves in a row into a movw.
> This is very basic, but i find it bad, because if the compiler places an
> instruction between both moves this pass wont be able to replace it with the
> movw. Also i find it very hacky, because the compiler doesnt know that there
> is really a move instruction that work with 16bit data so it doesnt have a
> global view of the costs and probably worsening reg allocation.
>
> If we worked with pseudo regs of 16 bits this should be straight forward,
> but we would face the problem i mentioned some time ago, all data operations
> would need custom lowering, because LLVM isnt able to split a wider reg into
> subregs (say R1312 into R13:R12). An initial guess would be manually
> splitting the reg into its subregs, perform the operation and finally
> recombining the subregs again into the bigger one for next instruction, but
> im not sure yet if this is a good solution.
>
> We really need to think about it because it's a very important design
> decision. This was my first email into llvm's dev mailing list, but i really
> didnt got any real solution.
> If you can think of any other points related to this, add them.
>
>