On January 26, 2016 8:00:52 PM GMT+01:00, Mike Stump <mikest...@comcast.net> wrote: >On Jan 26, 2016, at 10:21 AM, Jakub Jelinek <ja...@redhat.com> wrote >> The question is, shall we do what wi::lshift does and have the fast >path >> only for the constant shifts, as the untested patch below does, or >shall we >> check shift dynamically (thus use >> shift < HOST_BITS_PER_WIDE_INT >> instead of >> STATIC_CONSTANT_P (shift < HOST_BITS_PER_WIDE_INT) >> in the patch), > >Hum… I think I prefer the dynamic check. The reasoning is that when >we fast path, we can tolerate the conditional branch to retain the fast >path, as most of the time, that condition will usually be true. If the >compiler had troubles with knowing the usual truth value of the >expression, seems like we can hint that it will be true and influence >the static prediction of the branch. This permits us to fast path >almost all the time in the non-constant, but small enough case. For >known shifts, there is no code gen difference, so it doesn’t matter.
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. Richard.
