https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123314
--- Comment #4 from Pengfei Li <pfustc at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #3)
> I think we're tripping over statements that haven't been entered into the IL
> yet maybe?
Yes, this matches what I'm seeing too.
> It seems likely that this is expansion code being built and that perhaps the
> stmt defining patt_74 missed having the BB set on it?
The statement defining patt_74 is intentionally not part of the IL, because
it's a temporary GIMPLE created by the pattern recognition during the
vectorization analysis stage. Such statement may never be inserted into the IL
if vectorization is rejected then.
I'm experimenting with handling this in range_of_expr: if an SSA name has a
defining statement but gimple_bb (def_stmt) == NULL, we may just return a
VARYING range instead of performing more queries. Something like the following
seems to work:
diff --git a/gcc/gimple-range.cc b/gcc/gimple-range.cc
index f64c53a7371..f66beab8679 100644
--- a/gcc/gimple-range.cc
+++ b/gcc/gimple-range.cc
@@ -141,6 +141,8 @@ gimple_ranger::range_of_expr (vrange &r, tree expr, gimple
*stmt)
else
range_of_stmt (r, def_stmt, expr);
}
+ else if (def_stmt && gimple_bb (def_stmt) == NULL)
+ r.set_varying (TREE_TYPE (expr));
// Otherwise OP comes from outside this block, use range on entry.
else
range_on_entry (r, bb, expr);
I’m open to suggestions if there’s a better way to handle this.
