Andrea Arcangeli wrote:

> > Trivial functions would typically benefit most from a register-based
> > calling convention. But in practice, a function as trivial as `return
> > ++t' wouldn't be a separate function. And the simple functions that do
> > exist in a real world program would often be inlined. So this example
> 
> Right.
> 
> > doesn't really tell us how much difference a register-based calling
> > convention would make to real world programs.
> 
> This is true. The program show the best case (I just said this). The fact
> is that I can' t see the regparm(1) worst case to perform worse than
> regparm(0). I see regparm(1) only as an improvement that in the best case
> can help much and in the worse case will simply will not help. So why not
> go fast in the best case?

Right. So why not just declare the function as `inline'. This will be
faster than making it a separate function, whatever the calling
convention.

The point that I am making is that regparm(1) will only make a
significant difference for trivial functions. If you need to perform a
multiply or to call another function, and need to reference the
parameter afterwards, then you need to store the parameter anyhow.

And trivial functions should be inlined. If they are called within a
loop, then inlining the function may allow for additional
optimisations (e.g. loop induction), which are often far more
significant than just avoiding the function call overhead.

> Is there a case where regparm(1) hurt more than regparm(0)? Note that
> there should be no differences in pushing eax on the stack inside the
> callee (is this the right spelling? ;-) or inside the caller.

The disadvantage with changing the calling convention is complexity. 
For me, the issue isn't whether regparm(1) might be slower; it's
whether regparm(1) would ever provide a non-negligible performance
increase in a real-world application.

-- 
Glynn Clements <[EMAIL PROTECTED]>

Reply via email to