[PATCH] Fix up wi::lrshift (PR c++/69399)

[Mike Stump]

On Jan 26, 2016, at 12:45 PM, Richard Biener <richard.guenther@gmail.com> wrote:
> The original reasoning was to inline only the fast path if it is known at compile time and otherwise have a call. Exactly to avoid bloating callers with inlined conditionals.

That’s part of it.  And generally, yes, we do that.  One other part is, from the comment:

         For variable-precision integers like wide_int, handle HWI                                                                                           
         and sub-HWI integers inline.  */

Before, we just did the shift directly.  This _was_ the fast path.  We bulk the fast path case by a shift check, because we want to ensure it is small enough to be well defined.  The code previously was the fast path, because almost all shifts ever run will be HWI or smaller and will be 63 bits or less shifted.  If we make the check static only, then we boost the existing fast path out into the subroutine call.  Since the condition is most always true and since the predicate is in a register for the subroutine call anyway, the extra check should be fairly light (one instruction slot, zero execution time, zero dependencies, one BHT slot pollution).  With 34 call sites, that should be around an additional 136 bytes to the executable.  I think that space is paid for by the speed different of the fast path and how often it hits.  But, would be nice to have a person that loves benchmarking compile times and just tell us which one is faster.  :-)  Anyone skilled at knowing which one is faster is free to change to the other form.  My confidence that I know which one is faster is small; I’m happy to defer to someone that is more confident than I.