https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91775
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |missed-optimization
Target| |x86_64-*-*, i?86-*-*
Status|UNCONFIRMED |NEW
Last reconfirmed| |2019-09-16
CC| |amker at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
IVOPTS considers
Candidate 3:
Var befor: ivtmp.6
Var after: ivtmp.6
Incr POS: before exit test
IV struct:
Type: unsigned int
Base: 1023
Step: 4294967295
Biv: N
Overflowness wrto loop niter: Overflow
thus decrement to zero candidates but not increment to zero. I'm not sure
why it rejects this - candidate cost seems OK. IVOPTs does consider
decrement to zero specially:
/* When the condition is a comparison of the candidate IV against
zero, prefer this IV.
TODO: The constant that we're subtracting from the cost should
be target-dependent. This information should be added to the
target costs for each backend. */
if (!elim_cost.infinite_cost_p () /* Do not try to decrease infinite! */
&& integer_zerop (*bound_cst)
&& (operand_equal_p (*control_var, cand->var_after, 0)
|| operand_equal_p (*control_var, cand->var_before, 0)))
elim_cost -= 1;
so there must be other differences (the != 0 offset in the address uses)
compensating for it.
Bin may be able to decipher the IVOPTs dump to say what causes another
IV to be selected.
