On 10/7/19 6:28 AM, Aldy Hernandez wrote:
>
> Fair enough. I guess I don't care what we settle on, inasmuch as we
> canonicalize into one true value. For some reason, I thought the above
> nonzero would cause you to cringe, I guess not :).
:-) Takes more than that these days.. And just to reiterate for the
larger audience what we discussed in IRC -- I'm absolutely for
canonicalization. We're just debating what the canonical form should be
and how to get there.
>
> Happily, normalizing into ~0 for signed and [1,MAX] for unsigned,
> simplified the patch because it on longer needs tweaks to
> ranges_from_anti_range.
Looks like it was ultimately far smaller than I expected. Unless we
haven't audited existing code looking for open-coded ~[0,0] tests.
>
> OK for trunk?
With a ChangeLog, yes.
>
> Aldy
>
> p.s. This still leaves open the issue with ipa_vr's handling of
> nonzero_p. As per my last message, I've adjusted it to check for either
> ~[0,0] or the [1,MAX] variant for unsigned, since before this patch
> there were two ways of representing the same thing. However, ipa-prop
> has no API (it open codes everything), as it has rolled its own version
> of "value ranges" with wide-ints.
>
> class GTY(()) ipa_vr
> {
> public:
> /* The data fields below are valid only if known is true. */
> bool known;
> enum value_range_kind type;
> wide_int min;
> wide_int max;
> bool nonzero_p (tree) const;
> };
>
> I'm tempted to leave the nonzero_p which checks for both ~0 and [1,MAX]:
>
> bool
> ipa_vr::nonzero_p (tree expr_type) const
> {
> if (type == VR_ANTI_RANGE && wi::eq_p (min, 0) && wi::eq_p (max, 0))
> return true;
>
> unsigned prec = TYPE_PRECISION (expr_type);
> return (type == VR_RANGE
> && TYPE_UNSIGNED (expr_type)
> && wi::eq_p (min, wi::one (prec))
> && wi::eq_p (max, wi::max_value (prec, TYPE_SIGN (expr_type))));
> }
>
> I don't care either way.
Sigh. I can live with either here as well. I'm hesitant to start
mucking around with it simply because it's well outside of where we've
got expertise.
jeff
