https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|INVALID |---
Status|RESOLVED |NEW
--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Alexander Monakov from comment #13)
> (In reply to Richard Biener from comment #12)
> > Of course for the testcase at hand it's all in
> > a single statement and no parens specify association (in case parens also
> > matter here, like in Fortran). The fortran frontend adds PAREN_EXPRs
> > as association barriers which also would prevent FMAs to be formed.
>
> Please note that in this testcase GCC is breaking language semantics by
> computing the same value in two different ways, and then using different
> computed values in dependent computations. This could not have happened in
> the abstract machine (there's a singular assignment in the original program,
> which is then used in subsequent iterations of the loop).
Hmm, OK. I think we have a separate bugreport for this kind of thing. I can't
seem to reproduce any vectorization for your smaller example though.
For SLP vectorization the main source of "duplication" is when we have
unvectorized uses of an SSA name (aka a LIVE def) and cannot use a lane
extract but retain the scalar computations. In the updated Sample Program
this happens once but the corresponding subgraph is then not profitable
to vectorize for me, so it must be something else.
