https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79826
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2017-03-03
Ever confirmed|0 |1
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
The vectorizer doesn't do anything to mark things aliased - it just emits
vectorized stmts in unfortunate order and dependence analysis in the RTL
scheduler is too weak to undo the harm.
For the testcase with restrict it shows that the vectorizer fails to transfer
any MR_DEPENDENCE_* (restrict) info from the original refs to the vector refs.
The vectorizer could also generate MR_DEPENDENCE_* info from data-ref analysis
itself (not just copying pre-existing stuff properly). In the past there were
patches for "data dependence export to RTL" which is something that nowadays
could be done (in some approximate way) via setting MR_DEPENDENCE_* from
data dependence analysis (but one has to carefully review RTL code like
unrolling if it properly handles MR_DEPENDENCE_* when copying BBs).
First and foremost the vectorizer needs to preserve existing MR_DEPENDENCE_*
(wouldn't help the testcase w/o restrict).
Then I think we want to do a simple scheduling of memory operations on GIMPLE
to reduce register pressure given on GIMPLE we have way more powerful
dependence analysis.
