https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125786
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Priority|P3 |P2
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
The issue is that we adjust the last VEC_COND_EXPR def to the combined
result but do not verify the original result is unused. We do the same
on older branches.
That said, we may not simply rewrite an ops[] definition.
Either we check the vcond0 def is single-use (but even DEBUG_STMTS would
then get a wrong value!) or we create a new VEC_COND_EXPR, replacing
the ops[] entry. Or we go for the case of constant 'comb' only.
I also don't see how the rewriting sufficiently guarantees 'comb' SSA
uses are defined before 'vcond0'. Possibly that we are able to fold
is enough of a guarantee, but it looks fragile to me.
Anyway, I have a patch that builds a new VEC_COND_EXPR (and also folds it).
For the testcase at hand we then just get
- _35 = _27 | _30;
+ _35 = { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 };
as diff.
