This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: optimizing calling conventions for function returns
On 5/23/06, Paul Brook <paul@codesourcery.com> wrote:
> Has work been done to evaluate a calling convention that takes error
> checks like this into account? Are there size/performance wins? Or am
> I just reinventing a variation on exception handling?
This introduces an extra stack push and will confuse a call-stack branch
predictor. If both the call stack and the test are normally predicted
correctly I'd guess this would be a performance loss on modern cpus.
I just finished writing a bunch of test cases to explore the idea. My
conclusion is that if the error returns are very infrequent (<<1%)
then this is a win. But if there are a significant number of error
returns this is a major loss.
These two instructions on the error return path are the killer:
addl $4, %esp
ret /* Return to error return */
Apparently the CPU has zero expectation that the address being jumped
to is code. In the calling routine I pushed the error return as data.
pushl $.L11 /* push return address */
So for the non-error path there is a win by removing the error
test/jmp on the function return. But taking the error path is very
expensive.
I'm experimenting with 50 line assembly programs on a P4. I do wonder
if these micro results would apply in a macro program. My test is
losing because the return destination had been predicted and the
introduction of the addl messed up the prediction. But in a large
program with many levels of calls would the return always be predicted
on the error path?
--
Jon Smirl
jonsmirl@gmail.com