Re: [avr-gcc-list] the framepointer

[Ruud Vlaming]

Hi Andy

Thanks for your elaborate explanation! This is a real help.
I allready spend quite some time to study the way gcc works, 
but you need a lot of background information to actually 
understand it well. And i am a complete newbie in this area.

It is clear to me that i have to primitive a picture of the 
larger problems that lie underneath the choices the
compiler has to make. Producing small code is only
one of the many things that have to be taken into
account. 

Maybe the 'one fits all' approach of gcc is not optimal. We now 
have a compiler that must suite a powerfull 64 bit chip as well 
as a embedded 8 bit chip. Also, I sometimes wished we had a 
language C-- . This would be like C, but closer to assembly 
and with more understanding of the machine. The compiler
that should come with it should lack the optimization jungle
gcc now has. Optimization can best be done by hand, when
the code is not to big (which is usually the case in situations
where space is expensive)

For the time being i try to keep the memory hungry frame 
pointers in their cages by tying the variables gcc chooses
for fp to fixed registers. It is a work around, and does
not always work, but in most cases the compiler then gets
there is a register free he had missed, and the framepointer
disappears.

Ruud.

On Monday 21 April 2008 00:39, you wrote:
> 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.
> >   
>