On 6/30/21 2:20 AM, Aldy Hernandez wrote:
On 6/29/21 9:09 PM, Andrew MacLeod wrote:
We added context to a lot of simplify_using_ranges, but we didn't
catch all the places. This provides the originating stmt to the
missing cases which resolve a few EVRP testcases when running in
ranger-only mode.
Bootstraps on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
Thanks for doing this. I've done a half-assed job at passing context
around; probably only when it yielded a discrepancy with evrp.
bool
-simplify_using_ranges::op_with_boolean_value_range_p (tree op)
+simplify_using_ranges::op_with_boolean_value_range_p (tree op,
gimple *s)
{
if (TYPE_PRECISION (TREE_TYPE (op)) == 1)
I know you like single letter arguments, but I find them confusing
when the method is more than a few lines long. Besides, "stmt" is
what is used throughout vr-values.c.
And speaking of passing statements around, I wonder if it'd be best to
have m_stmt and possible m_gsi as class fields. After all, we never
change them, and they're used by most methods.
Aldy
I think there's a revamp of simplify down the pipe anyway.
class simplify_using_ranges
{
public:
simplify_using_ranges (class range_query *query = NULL);
~simplify_using_ranges ();
void set_range_query (class range_query *q) { query = q; }
bool simplify (gimple_stmt_iterator *);
This is really the only external API.. the call to simplify. Long term
Im not sure that containing all the switch update management stuff att
he bottom of the class should be contained in this class.. That seems
like it should be a class that is used by simplifcation... and
simplification itself could be stateless.. kinda following the model
of fold_using_ranges.. the the gsi and stmt can be wrapped into a source
class if needed...
likewise we're eventually going to want to restructure the folding stuff
that happens.. but most of this can wait until evrp and vrp are gone,
then we can change the model a bit easier. bigger fish to fry and they
are already way better than they were before :-)
