[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