[PATCH 2/4] libata-core.c: add another IRQ calls

[Mikael Pettersson]

Jeff Garzik writes:
 > Mikael Pettersson wrote:
 > > 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.
 > 
 > 
 > To be a bit more specific, the branch being taken, or not, depends on 
 > the system setup.  For example, in sata_promise's case, with no other 
 > SATA controllers in use,
 > 
 > 	if (ap->ops->irq_on)
 > 		ap->ops->irq_on(ap);
 > 	else
 > 		ata_irq_on(ap);
 > 
 > the direct function call will ALWAYS be called.  But if you had a weird 
 > system with both Cell and Promise PDC203xx, then the branch is dependent 
 > on whether the activity comes from the Cell SATA or Promise SATA.
 > 
 > So it's highly predictable in a great many cases.
 > 
 > And it should be noted that it is a direct function call not inline, 
 > thus its if/indirect/direct not if/indirect/inline.
 > 
 > Does that change the answer at all?

The real benefits from identifying a common case is to inline
the code for it. So the fact that the common case is still a
full-blown function call here and not inline code means that
there's much less benefit from rewriting an indirect call as
an if/indirect/direct sequence.

There is some branch prediction benefit from having
if/call-indirect/call-direct-to-common-case instead of a
single call-indirect, but only if the common case really is
much more common than other cases, or if the other cases
are limited to just one (so there's two common cases).

I wouldn't change a call-indirect to if/call-indirect/call-direct
unless it's on a very hot path with a known dominant common case.