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?
