https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67326
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Keywords| |missed-optimization
Last reconfirmed| |2015-08-25
CC| |rguenth at gcc dot gnu.org,
| |venkataramanan.kumar at amd
dot co
| |m
Ever confirmed|0 |1
Summary|[5.2/6.0 regression] |[5/6 Regression]
|-ftree-loop-if-convert-stor |-ftree-loop-if-convert-stor
|es does not vectorize |es does not vectorize
|conditional assignment |conditional assignment
|(anymore) |(anymore)
Target Milestone|--- |6.0
Severity|normal |enhancement
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
This is because in condAssign1 v3 is not accessed always and thus we do not
know (ok, stupid ifcvt limitation) that v3[i] is not accessed out-of-bounds.
Previous to
2015-07-10 Richard Biener <rguent...@suse.de>
PR tree-optimization/66823
* tree-if-conv.c (memrefs_read_or_written_unconditionally): Fix
inverted predicate.
ifcvt's reasoning was "oh, "v3[i] is _not_ equal to v2[i] which is always
accessed, thus it's fine to access it always as well". I fixed this bug
but did not try to enhance ifcvts idea of what operations can trap
(v3[i] is thought to eventually trap because we do not try to analyze
what values 'i' can have).
So in 4.9 and earlier this only works becuase of the above bug. So, kind
of "confirmed", but it's really an enhancement request. AFAIR Venkat is
working
in this area.
