[Bug middle-end/21990] Wrong code for 4.0 and head: Reload clobbers the frame pointer by using it as spill register without recognizing the clobbering

["bjoern dot m dot haase at web dot de" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From bjoern dot m dot haase at web dot de  2005-09-03 14:25 -------
Hi, 
 
I now think that the true origin of this PR is related to the fact that for AVR 
we need *two* registers for holding the frame pointer: 
 
Recently, I have played around with modifying avr-gcc by choosing different 
registers for the frame pointer and the stack pointer. Namely I have 
experimented with the calling convention used by the IAR system (use two 
seperate stacks for the return addresses and data). 
It turned out that the stack pointer and frame pointer register number during 
my experiments that was used by gcc was not 28 but 29! 
 
Possibly one would have to re-investigate avr_hard_regno_mode_ok(REGNO, MODE) 
function in avr.c that implements the HARD_REGNO_MODE_OK target macro. IIUC, 
there have been a couple of problems in the past with similar results: 
clobbered frame pointer. Maybe the fact that this bug does not show up 
frequently has to do with that the constraints for the Y register implemented 
in avr_hard_regno_mode_ok are fairly restrictive right now, so that the 
register allocator and reload almost never are tempted to use it. 
 
Important information would be wether avr_hard_regno_mode_ok is evaluated 
dynamically for each function. In this case one could probably prevent 
clobbering of the frame pointer by denying any mode in regs 28 and 29 in case 
that a frame pointer is needed. This way one possibly could also lift the 
present restriction that only pointers (Pmode objects) may be held in the y 
register. 
 
So I think that we are right now having a hidden problem in avr-gcc that shows 
up only in very rare occasions. Most probably it's also present in the 3.4.4 
series. 
 
Yours, 
 
Björn 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21990