[Bug tree-optimization/96397] GCC Fails to exploit ranges from overflow tests

[aldyh at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu.org,
                   |                            |amacleod at redhat dot com

--- Comment #1 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
>From a previous conversation with Jeff, I believe the corresponding IL is this:

;;   basic block 11, loop depth 0, count 487351684 (estimated locally), maybe
hot
;;   Invalid sum of incoming counts 749887186 (estimated locally), should be
487351684 (estimated locally)
;;    prev block 10, next block 12, flags: (NEW, REACHABLE, VISITED)
;;    pred:       18 [82.6% (guessed)]  count:749887186 (estimated locally)
(FALSE_VALUE,EXECUTABLE)
  _109 = .ADD_OVERFLOW (_106, 1);
  _110 = REALPART_EXPR <_109>;
  # DEBUG size => _110
  _111 = IMAGPART_EXPR <_109>;
  # DEBUG fail => (_Bool) _111
  if (_111 != 0)
    goto <bb 17>; [17.38%]
  else
    goto <bb 12>; [82.62%]

The ranger knows that _111 can only be [0,1], but we don't currently have a
backwards solver for the IMAGPART_EXPR code.  Currently it's unimplemented as
"op_unknown".  I suppose we could implement it, and the ranger should be then
able to solve for _109 (and eventually _106).

It would take a little twiddling, since range-ops currently doesn't look at
USE/DEF chains, and it would have to for the IMAGPART_EXPR since not all
IMAGPART_EXPR's are created equal.  E.g. for DEF's of .ADD_OVERFLOW, it means
something totally different than the IMAGPART_EXPR of a complex number.

Andrew, can you verify this is doable with minor tweaks?