On 01/30/2010 06:48 PM, Ian Lance Taylor wrote:
Uros Bizjak<ubiz...@gmail.com> writes:The target that I would like to support has 8-bit registers, so for any sane compilation, stack pointer, frame pointer and hard frame pointer all need to be constructed from at least two registers, to form 16-bit register pair {rA, rB}. The stack pointer is defined as a fixed register, so it is not reachable to register allocator. The frame pointer is actually a fake register (with a regnum above last hard register regnum) that eliminates either to SP or HW_FP, so RA ignores it. The problem is with HW_FP. Looking at the register allocator, it seems that only HARD_FRAME_POINTER_REGNO is marked as live in the allocator, although hard_frame_pointer_rtx shows itself as a HImode register with H_F_P_R register number. Since H_F_P_R+1 is marked "empty", RA puts various QImode values there, clobbering high part of hard frame pointer. There is nothing in the documentation that would describe this limitation, and I found no solution browsing the web archives. Also, I believe that AVR should have the same problems. Is this a known limitation in the RA? If it is, is there a solution for multi-reg [HARD]_FRAME_POINTER?I think the AVR does it by treating the soft frame pointer as a pair of registers, and eliminating both registers, one to HARD_FRAME_POINTER_REGNO and the other to HARD_FRAME_POINTER_REGNO+1. Make the elimination conditions the same, and the compiler should reliably eliminate either both or neither.
Unfortunately, your proposed solution doesn't work, no matter if I specify all high-part registers (i.e. FRAME_POINTER_REGNUM+1 and HARD_FRAME_POINTER_REGNUM+1) as eliminable pairs.
It looks that register allocator is just not prepared to eliminate all registers of multi-reg soft frame pointer to hard frame pointer (it only eliminates strictly FRAME_POINTER_REGNUM to HARD_FRAME_POINTER_REGNUM registers).
Probably, this is the reason that AVR port doesn't use H_F_P_R and defines F_P_R directly as hardware register pair. This solution works, but probably disables optimization or two. I have Cc'd AVR maintainers, perhaps they have some information to share.
Thanks, Uros.
