On 8/16/22 05:28, Richard Biener wrote:
On Tue, 16 Aug 2022, Aldy Hernandez wrote:
On Tue, Aug 16, 2022 at 11:08 AM Aldy Hernandez <al...@redhat.com> wrote:
On Tue, Aug 16, 2022 at 10:32 AM Richard Biener <rguent...@suse.de> wrote:
On Tue, 16 Aug 2022, Aldy Hernandez wrote:
On Thu, Aug 11, 2022 at 1:42 PM Richard Biener <rguent...@suse.de> wrote:
@@ -599,6 +592,30 @@ path_range_query::compute_imports (bitmap imports, const
vec<basic_block> &path)
worklist.safe_push (arg);
}
}
+ else if (gassign *ass = dyn_cast <gassign *> (def_stmt))
+ {
+ tree ssa[3];
+ if (range_op_handler (ass))
+ {
+ ssa[0] = gimple_range_ssa_p (gimple_range_operand1 (ass));
+ ssa[1] = gimple_range_ssa_p (gimple_range_operand2 (ass));
+ ssa[2] = NULL_TREE;
+ }
+ else if (gimple_assign_rhs_code (ass) == COND_EXPR)
+ {
+ ssa[0] = gimple_range_ssa_p (gimple_assign_rhs1 (ass));
+ ssa[1] = gimple_range_ssa_p (gimple_assign_rhs2 (ass));
+ ssa[2] = gimple_range_ssa_p (gimple_assign_rhs3 (ass));
+ }
+ else
+ continue;
+ for (unsigned j = 0; j < 3; ++j)
+ {
+ tree rhs = ssa[j];
+ if (rhs && add_to_imports (rhs, imports))
+ worklist.safe_push (rhs);
+ }
+ }
We seem to have 3 copies of this copy now: this one, the
threadbackward one, and the original one.
Could we abstract this somehow?
I've thought about this but didn't find any good solution since the
use of the operands is always a bit different. But I was wondering
why/if the COND_EXPR special-casing is necessary, that is, why
don't we have a range_op_handler for it and if we don't why
do we care about it?
Simply that range-ops is defined as always being one or 2 use operands.
everything is streamlined for those common cases. There is no support
in the API for a 3rd field. All non-conforming stmts are "unique" and
thus require some level of specialization. I am not aware of any other
3 operand stmt we would care about, so at the time it seemed easier to
leave cond-expr as a specialization, in theory localized.
as for the abstraction, its easy enough to provide a routine which will
take a vector and fill it with ssa_names we might care about on the
stmt.. then each caller can do their own little specialized bit. I
never expected for that sequence to become common place :-)
I think it's because we don't have a range-op handler for COND_EXPR,
opting to handle the relational operators instead in range-ops. We
have similar code in the folder:
if (range_op_handler (s))
res = range_of_range_op (r, s, src);
else if (is_a<gphi *>(s))
res = range_of_phi (r, as_a<gphi *> (s), src);
else if (is_a<gcall *>(s))
res = range_of_call (r, as_a<gcall *> (s), src);
else if (is_a<gassign *> (s) && gimple_assign_rhs_code (s) == COND_EXPR)
res = range_of_cond_expr (r, as_a<gassign *> (s), src);
Andrew, do you have any suggestions here?
Hmmm, so thinking about this, perhaps special casing it is the way to go ??
It looks like so. Though a range_op_handler could, for
_1 = _2 ? _3 : _4; derive a range for _3 from _1 if _2 is
known true?
the fold_using_range class does this for the forward direction, and my
intention (just havent gotten to it yet), was to add similar
specialization in GORI rather than expanding range-ops just for the one
stmt... in much the same way that range_of_cond_expr works.
It should be localized to gori_compute::compute_operand_range () , where:
range_op_handler handler(stmt);
if (!handler)
return false;
before returning, we check if its a COND_EXPR, and if so, call a
specialized compute routine to look at the various operands and invoke
any continued operand ranges as approriate. It should be quite trivial..
I'll take a look at adding COND_EXPR to GORI, and privoide that
routine somewhere.. probably as a function as part of
gimple-range-fold.h so it can potentially apply to any stmt.
Andrew
