https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115004
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |daniel.barboza at oss dot
qualcomm
| |.com
--- Comment #6 from Jeffrey A. Law <law at gcc dot gnu.org> ---
So with the recent fix for 90036 we actually get just about everything we need
into the hash table. In particular we have these blocks:
;; basic block 3, loop depth 0
;; pred: 2
_1 = p1_11(D) != 0;
_2 = p2_12(D) != 0;
_3 = _1 | _2;
_33 = p5_13(D) != 0;
_32 = _3 | _33;
if (_32 != 0)
goto <bb 4>; [75.00%]
else
goto <bb 7>; [25.00%]
;; basic block 4, loop depth 0
;; pred: 3
if (_3 != 0)
goto <bb 7>; [50.00%]
else
goto <bb 5>; [50.00%]
;; succ: 7
;; 5
;; basic block 5, loop depth 0
;; pred: 4
if (p5_13(D) == 0)
goto <bb 6>; [100.00%]
else
goto <bb 7>; [0.00%]
;; succ: 6
;; 7
As we enter bb5 we note that _3 must have the value 0 (via the 4->5 edge) and
we already know that _32 must be 1 (it's boolean) due to traversing edge 3->4.
Those two ultimately result in _33 getting the value 1 (again it's a boolean).
We later lookup p5_13 == 0 in the hash table and find nothing. Why? Because
the hash table only has 1 = p5_13 != 0 recorded.
That's just kind of how eliminate_reundant_computations works for assignments.
It's set up to do a single lookup of the expression, entering it into the hash
table on a miss. So the assignment in bb3 triggers a single hash table
insertion of _33 = p5_13 != 0.
ISTM we could notice we're dealing with an RHS that is a COND_EXPR and enter
multiple expressions in the table. Or we could do multiple lookups. We
already have code to do an additional lookup on a hash table miss for certain
codes. For example, if we miss on max (a, b), we can lookup a >= b and return
a if its true or b if its false.
Anyway, going to ponder overnight. Much like 90036, this is going to be hard
for Ranger to discover, but its pretty easy for DOM. In fact it was so close
to 90036, that I expected those changes to be sufficient.
