Re: [avr-gcc-list] the framepointer

[Andy H]

Ruud,

I glad you take the time to highlight problems.

As you noted fomit-frame-pointer is not an absolute.

For AVR the condition for elimination  is stack slots > 0, calloc used 
and something I cant remember.

What you see is stack slots >0. Again I'd have to study in detail to see 
why it wanted stack slot (taking address of a var is one reason it 
happens of course). Cost does come into it. If the allocator figures its 
cheaper to use memory than register it will do.

Now despite how it's currently coded, it is possible to have NO frame 
pointer yet still have stack slots for AVR. Indeed I have version that 
does this (debugging other stuff)
Here it uses stack pointer instead. To get at stack slot it move SP to a 
base register.  Quite often it produces smaller code - though I have not 
completely figured out why nor tested it much. (One reason is that it 
can avoid saving R28 and use R30 instead.)

In the ideal world the compiler should be able to optimally use 
registers to access stack slots without needing specific frame pointer. 
So stack slots > 0 should not be required condition.
Im not sure how close gcc gets to this ideal yet.

Stacks slots > 0 is very problematic to register allocation. What 
happens is that register allocation starts off assuming no frame pointer 
and will use R28,29. When it find it needs stack slot, it has to bump 
(spill) any use it has already made of R28,r29. Ironically, if the 
existing use is as a pointer into the stack  and there is no other base 
register available gcc will fail - it is not smart enough to know at 
this point that a frame pointer is available!

So one of my patches (yet to be approved) uses R26,27 as substitute to 
avoid failure. The actual code ends up using r2829 - when gcc eventually 
figures in the frame pointer - VERY FRUSTRATING

It so happens I rewriting my prolog to properly allow no-frame-pointer, 
regardless of stack slots.  Not for you, but to avoid problems with new  
IRA register allocator which may be used in future.


Andy


Ruud Vlaming wrote:
> On Saturday 19 April 2008 23:26, you wrote:
>
>   
> > The save around call will not use R18 upwards, 
> > as these are call clobbered. 
> >     
> You'r right.
>
>   
> > Without studying source and compiler RTL and optimisation level used  I 
> > cannot say why it did not use a lower register.
> > It may be the cost assumptions are not quite right for a low number of 
> > slots compared to reg push/pops..
> >     
> Maybe this is a little dumb, but i asked the compiler with -fomit-frame-pointer
> explicitly to not use the frame pointers if avoidable. Then it should not
> weight any costs, it should simply do push/pop for one variable (or use a 
> lower register). Even if it is much more expensive. Only when it is not 
> avoidable it should use framepointers, but if you do not explictly alloc 
> some space and your functions are not to complex/long this should be rare.
> Thus, in my view this is not a matter of optimization.
>
> My knowledge of the gcc internals is near to zero so i have a hard time
> finding the right spots to analyze this. Any comments appreciated.
>
>   
> > The reason you don't have RTL prolog/epilog is that it takes forever to 
> > get patches approved.  I think I wrote it in 2005 for 4.1 !
> >     
> Argh! And i thought our goverment was slow ....
>
> greetings
> Ruud.
>