[PATCH 2/4] libata-core.c: add another IRQ calls
Mikael Pettersson
mikpe at it.uu.se
Wed Jan 17 20:24:54 EST 2007
On Tue, 16 Jan 2007 17:04:27 -0500, Jeff Garzik wrote:
>Alan wrote:
>> Jeff - at some point we could eliminate a lot of the NULL checks like
>> these by having the registration code fill in the defaults where
>> appropriate ?
>
>libata policy up until this point has been to require all drivers fill
>in the hook, either with the commonly-used default, or with their own
>variant. Thus, no NULL checks for required hooks, and you get an oops
>if you fail this requirement. I like that better than defaults buried
>inside libata-core, where it is easier for programmers to forget them.
>
>But actually, it's an open question for the compiler guys whether this
>case is preferred:
>
> if (ap->ops->hook)
> ap->ops->hook(foo, bar);
> else
> commonly_used_default(foo, bar);
>
>or this:
>
> ap->ops->hook(foo, bar);
>
>With advanced branch prediction in modern CPUs, ISTR the first case may
>be worth considering, even with the branch.
Indirect function calls incur at least two main costs:
- the 'call *' instruction itself suffers from poor branch
prediction unless the HW is clever and the call patterns
are highly biased -- most machines have worse branch
predictors for indirect jumps than for direct jumps
- the compiler must generate code for setting up parameters
and spilling the caller's registers, and for reloading the
caller's registers after the call
If there is a highly common case, the code for that case
is available, and the code is cheap to execute (doesn't
require too many additional variables), then having an
explicit test + inline code is preferred. If any of these
conditions isn't met, then I wouldn't bother converting
the call to the if/inline/call combo.
There are compilers for OOP languages that routinely use
rewrites like the one above in order to optimise method calls.
/Mikael
More information about the Linuxppc-dev
mailing list