https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119683
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Right now I see 3 spots which use get_global_range_query ()->range_of_expr
(vrY, @X)
and then various other spots that use get_range_query (cfun)->range_of_expr
(vrY, @X)
I wonder if the outermost stmt is the right context though.
When we have say
(mult (plus:s (mult:s@4 @0 INTEGER_CST@1) INTEGER_CST@2) INTEGER_CST@3)
and want to query range of @4, shouldn't we be querying it on the plus stmt?
I.e. add @5 to it
(mult (plus:s@5 (mult:s@4 @0 INTEGER_CST@1) INTEGER_CST@2) INTEGER_CST@3)
and have some helper function which checks whether @5 is SSA_NAME with
SSA_NAME_DEF_STMT non-NULL and in some bb (would that be sufficient to avoid
the problems with queries on expressions or stmts not in the IL)?
And let the helper function return NULL if it can't figure the stmt or
something to pass to get_range_query (cfun)->range_of_expr as the third
statement, so it will be
get_range_query (cfun)->range_of_expr (vr0, @4, stmt_ctx (@5))
?
As an untested POC
--- gcc/match.pd.jj 2025-11-25 10:03:25.201911338 +0100
+++ gcc/match.pd 2025-11-25 15:02:40.524540362 +0100
@@ -4432,7 +4432,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
/* ((T)(A)) + CST -> (T)(A + CST) */
#if GIMPLE
(simplify
- (plus (convert:s SSA_NAME@0) INTEGER_CST@1)
+ (plus (convert:s@2 SSA_NAME@0) INTEGER_CST@1)
(if (TREE_CODE (TREE_TYPE (@0)) == INTEGER_TYPE
&& TREE_CODE (type) == INTEGER_TYPE
&& TYPE_PRECISION (type) > TYPE_PRECISION (TREE_TYPE (@0))
@@ -4450,7 +4450,12 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
TYPE_SIGN (inner_type));
int_range_max vr;
- if (get_global_range_query ()->range_of_expr (vr, @0)
+ gimple *stmt_ctx = NULL;
+ if (TREE_CODE (@2) == SSA_NAME
+ && SSA_NAME_DEF_STMT (@2)
+ && gimple_bb (SSA_NAME_DEF_STMT (@2)))
+ stmt_ctx = SSA_NAME_DEF_STMT (@2);
+ if (get_range_query (cfun)->range_of_expr (vr, @0, stmt_ctx)
&& !vr.varying_p () && !vr.undefined_p ())
{
wide_int wmin0 = vr.lower_bound ();
fixes the testcase.
