On Tue, Jan 26, 2016 at 11:00:52AM -0800, Mike Stump 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.
Ok, I've cancelled my pending bootstrap/regtest and am testing this instead:
2016-01-26 Jakub Jelinek <ja...@redhat.com>
PR tree-optimization/69399
* wide-int.h (wi::lrshift): For larger precisions, only
use fast path if shift is known to be < HOST_BITS_PER_WIDE_INT.
--- gcc/wide-int.h.jj 2016-01-04 18:50:34.656471663 +0100
+++ gcc/wide-int.h 2016-01-26 20:07:03.147054988 +0100
@@ -2909,7 +2909,9 @@ wi::lrshift (const T1 &x, const T2 &y)
For variable-precision integers like wide_int, handle HWI
and sub-HWI integers inline. */
if (STATIC_CONSTANT_P (xi.precision > HOST_BITS_PER_WIDE_INT)
- ? xi.len == 1 && xi.val[0] >= 0
+ ? (shift < HOST_BITS_PER_WIDE_INT
+ && xi.len == 1
+ && xi.val[0] >= 0)
: xi.precision <= HOST_BITS_PER_WIDE_INT)
{
val[0] = xi.to_uhwi () >> shift;
Jakub
