combine two load insns

Andrew Stubbs andrew.stubbs@gmail.com
Sun Dec 12 17:11:00 GMT 2010


On 08/12/10 14:39, Jeff Law wrote:
 >> Sorry, I think I wasn't clear. I didn't mean constraints in term on
 >> RTL template constraints, but 'constraints' coming from the new DI
 >> destination of the load. More specifically: 2 SI loads can target
 >> totally independent registers whereas a standard DI load must target a
 >> contiguous SI register pair. If you don't do that before IRA, it will
 >> most likely be impossible to do cleanly, won't it?
 >
 > I tend to look at it the other way -- prior to allocation & reload
 > you're going to have two SImode pseudos and there's no way to guarantee
 > they'll end up in consecutive hard registers.  You'd have to create a
 > new DImode pseudo as the destination of the memory load, then copy from
 > the DImode pseudo into the two SImode pseudos and rely on the register
 > allocator to allocate the DImode pseudo to the same hard registers as
 > the two SImode pseudos.  There's no guarantee that'll happen (it often
 > will, but in the cases where it doesn't you end up with useless copies).

Fred's approach seems like the obviously 'better' way to me, although no 
doubt Jeff's way is easier to handle.

I've been musing about the best way to handle the ARM ldm/stm 
instructions that can coalesce an arbitrary number of register 
loads/stores into a single instruction. The only constraint is that the 
values must always appear in the same order in memory as in the register 
file. There is no requirement for contiguity.

Right now, the compiler does support ldm/stm, but only to a limited 
extent. I've yet to absorb it fully, but I think it's limited to 4 
registers at once, and relies on the registers being allocated helpfully.

It would be nice if the register allocator could be ldm/stm aware, 
somehow. It would also be nice if this could be done in such a way that 
ldm/stm could be used in asm inserts, given the right constraints.

It would be nice ...

Andrew



More information about the Gcc mailing list