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. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
