[Bug tree-optimization/107043] range information not used in popcount

["aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107043

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu.org

--- Comment #3 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)

> int g1(int n)
> {
>   int n1 = n & 0x8000;
>   if (n1 == 0)
>     return 1;
>   // n>>15 will be xxxxxx1 here.
>   return (n >> 15) & 0x1;
> }

Interestingly, getting this one requires us to track something completely
different, the bits that are *definitely* set.

[Right now we track the nonzero mask, which is a misnomer because we're not
tracking bits are nonzero but the bits that *may* be nonzero.  Or more
precisely the inverse of the bits that are known to be 0.  For example, a
"nonzero" mask of 0xfffffff0 means the least significant 8 bits are known to be
zero, and the rest of the bits are unknown.  So we're tracking the "and mask"
of a number?  Or the maybe_nonzero bits?  The reason for the name is because
legacy VRP had this name.]

To get the above, we'd need to track the bits that are definitely 1 (the "or
mask" of a number?).  For example, on the 2->4 edge we'd need to know that n_3
has the 0x8000 bit set:

  <bb 2> :
  n1_4 = n_3(D) & 32768;
  if (n1_4 == 0)
    goto <bb 3>; [INV]
  else
    goto <bb 4>; [INV]

  <bb 3> :
  goto <bb 5>; [INV]

  <bb 4> :
  _1 = n_3(D) >> 15;
  _5 = _1 & 1;

  <bb 5> :
  # _2 = PHI <1(3), _5(4)>
  return _2;

What we're looking for is solving n_3:

[not-zero] = n_3 & 32768

which should give us:

[-INF,-1][32768, +INF] ORMASK [0x8000]

or whatever the hell we want to call it.  I hate these names.  Please someone,
come up with a name that makes sense to us all!

Andrew M and I had a plan for this earlier this cycle, but got sidetracked by
floats.  What we'd need is a way to track or-mask's in addition to and-masks.

There's actual infrastructure missing here, but it should be as easy as what we
did for "nonzero" tracking in commit 4e82205b68024f5c1a9006fe2b62e1a0fa7f1245
(plus supporting patches).  Basically we need to add a slot for the or-mask in
the irange, add union/intersect code, and then add some glue in range-ops to
solve:

1 = x & mask
x = y | mask
etc etc.

Thanks for the testcase, it's quite useful.