Erik,
You misunderstand.
GCC creates register allocations for C/C++ statements - not the
programmer. The ABI allows the programmer to play with r0 in assembler.
It does so because the assumption is that GCC will not use it _across_
asm statements or across functions calls.
Similary R1 must be restored by the user - as GCC will use it for a zero
across more or less everything.
GCC avr backend also uses R0 , This should only occur in a single RTL
instruction, so the scope is limited.
ie use of R0 in one RTL instruction will not affect another use.
In the case I was looking at, R0 was apparently allocated like an normal
register and used across several RTL instructions.
The one in between corrupted it.
Anyway, it turns out that it is a bug but the allocation is not the
problem at all.
We have avr specfic RTL pattern that uses R0. This instance requires
R0 to live across two other RTL instructions.
In rare circumstances these other RTL instructions also need to use r0
(for example if the pointers they use overlap destinations).
GCC has no way of knowing that these other instruction change r0 - so it
gets corrupted.
I am looking at what is best patch. One way is to not use R0 but a
regular register. But there may be a smarter ways
than adding further burden on the register allocator It does a better
job if you give it a head start!
I do know that the pattern of concern was initially created by myself.
So I suspect I only have myself to blame.
Andy
Erik Christiansen wrote:
On Fri, Jan 18, 2008 at 12:24:29AM -0500, Andrew Hutchinson wrote:
I think I have found a bug with avr register allocation.
Maybe not. ;-)
...
So R0 got trashed.
There will be other examples where this could happen as R0 is used is
quite a few places to help assembler.
But the avr ABI defines it as volatile, as I understand it. At
http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_reg_usage we
have:
r0 - temporary register, can be clobbered by any C code (except
interrupt handlers which save it), may be used to remember something
for a while within one piece of assembler code
<<<
Looks like we have licence to trash it.
I can only assume at this time that the same could happen to R1.
Nope, not a safe assumption. It must be restored if fiddled. It is
"assumed to be always zero in any C code".
Erik
_______________________________________________
AVR-GCC-list mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
_______________________________________________
AVR-GCC-list mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
