Re: [PATCH] Add value_range_base (w/o equivs)

[Jeff Law <law at redhat dot com>]

On 11/9/18 7:19 AM, Richard Biener wrote:
> 
> This adds value_range_base, a base class of class value_range
> with all members but the m_equiv one.
> 
> I have looked into the sole GC user, IPA propagation, and replaced
> the value_range use there with value_range_base since it also
> asserted the equiv member is always NULL.
> 
> This in turn means I have written down that GC users only can
> use value_range_base (and fixed the accessability issue with
> adding a bunch of friends).
> 
> I have moved all methods that are required for this single user
> sofar (without looking with others are trivially movable because
> they do not look at equivs - that's for a followup).  I ended
> up basically duplicating the ::union_ wrapper around union_ranges
> (boo).  Some more refactoring might save us a few lines here.
> 
> There are two places where IPA prop calls extract_range_from_unary_expr.
> I've temporarily made it use value_range temporaries there given
> I need to think about the few cases of ->deep_copy () we have in
> there.  IMHO equiv handling would need to move to the callers or
> rather "copies" shouldn't be handled by extract_range_from_unary_expr.
> Well, I need to think about it.  (no, I don't want to make that
> function virtual)
> 
> The other workers might be even easier to massage to work on 
> value_range_base only.
> 
> Bootstrap and regtest running on x86_64-unknown-linux-gnu.
> 
> If that goes well I want to apply this even in its incomplete form.
> Unless there are any complaints?
> 
> Thanks,
> Richard.
> 
> From 525e2e74bbb666399fafcffe8f17e928f45ca898 Mon Sep 17 00:00:00 2001
> From: Richard Guenther <rguenther@suse.de>
> Date: Fri, 9 Nov 2018 15:00:50 +0100
> Subject: [PATCH] add-value_range_base
> 
> 	* tree-vrp.h (class value_range_base): New base class for
> 	value_range containing all but the m_equiv member.
> 	(dump_value_range_base): Add.
> 	(range_includes_zero_p): Work on value_range_base.
> 	* tree-vrp.c (value_range_base::set): Split out base handling
> 	from...
> 	(value_range::set): this.
> 	(value_range::set_equiv): New.
> 	(value_range_base::value_range_base): New constructors.
> 	(value_range_base::check): Split out base handling from...
> 	(value_range::check): this.
> 	(value_range::equal_p): Refactor in terms of
> 	ignore_equivs_equal_p which is now member of the base.
> 	(value_range_base::set_undefined): New.
> 	(value_range_base::set_varying): Likewise.
> 	(value_range_base::dump):Split out base handling from...
> 	(value_range::dump): this.
> 	(value_range_base::set_and_canonicalize): Split out base handling
> 	from...
> 	(value_range::set_and_canonicalize): this.
> 	(value_range_base::union_): New.
> 
> 	* ipa-prop.h (struct ipa_jump_func): Use value_range_base *
> 	for m_vr.
> 	* ipa-cp.c (class ipcp_vr_lattice): Use value_range_base
> 	instead of value_range everywhere.
> 	(ipcp_vr_lattice::print): Use dump_value_range_base.
> 	(ipcp_vr_lattice::meet_with): Adjust.
> 	(ipcp_vr_lattice::meet_with_1): Likewise.
> 	(ipa_vr_operation_and_type_effects): Likewise.
> 	(propagate_vr_across_jump_function): Likewise.
> 	* ipa-prop.c (struct ipa_vr_ggc_hash_traits): Likewise.
> 	(ipa_get_value_range): Likewise.
> 	(ipa_set_jfunc_vr): Likewise.
> 	(ipa_compute_jump_functions_for_edge): Likewise.
I like it.  Hell, I wish someone had suggested it last year, I could
have taken care of it then.

jeff