https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104402
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think the best would be to to keep the condition split out since that's
desirable anyway from an IL perspective (we've only covered VEC_COND_EXPR
there).
> grep '\?' t.c.*
t.c.039t.evrp: _7 = _4 ? 3 : 2;
so EVRP introduces this.
t.c.108t.forwprop2: _5 = a.1_3 != __complex__ (0, 0) ? 3 : 2;
and forwprop moves the condition in.
A quick workaround would thus be to disable propagating complex compares
into COND_EXPRs from forwprop but then treating _Complex like vector and
forcing is_gimple_condexpr to return false for composite types would be
a good step with likely not much fallout.
Btw, since vector type equality compares can return a bool as well we can
in theory see
vec1 != vec2 ? scalar1 : scalar2;
which we might not handle in vector lowering either. is_gimple_condexpr
is the predicate to adjust here. For example like the following (but
the factoring with is_gimple_condexpr_for_cond makes it a bit awkwardly
inefficient):
diff --git a/gcc/gimple-expr.cc b/gcc/gimple-expr.cc
index 05b12747499..b71f7afb686 100644
--- a/gcc/gimple-expr.cc
+++ b/gcc/gimple-expr.cc
@@ -615,6 +615,9 @@ is_gimple_condexpr_1 (tree t, bool allow_traps)
bool
is_gimple_condexpr (tree t)
{
+ if (COMPARISON_CLASS_P (t)
+ && TREE_CODE (TREE_TYPE (TREE_OPERAND (t, 0))) == COMPLEX_TYPE)
+ return false;
return is_gimple_condexpr_1 (t, true);
}
