[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] the framepointer

From: Andy H
Subject: Re: [avr-gcc-list] the framepointer
Date: Sun, 20 Apr 2008 18:39:45 -0400
User-agent: Thunderbird (Windows/20080213)


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.


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 ....


reply via email to

[Prev in Thread] Current Thread [Next in Thread]