[Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569

--- Comment #34 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #33)
> (In reply to Jakub Jelinek from comment #31)
> > Created attachment 53873 [details]
> > gcc13-pr107569-div.patch
> > 
> > This is what I meant by complete nightmare - division.
> 
> We can take this to gcc-patches when you're done, but just a few thoughts...
> 
> +    // If +-0.0 is in both ranges, it is a maybe NAN.
> +    if (real_compare (LE_EXPR, &lh_lb, &dconst0)
> +	&& real_compare (GE_EXPR, &lh_ub, &dconst0)
> +	&& real_compare (LE_EXPR, &rh_lb, &dconst0)
> +	&& real_compare (GE_EXPR, &rh_ub, &dconst0))
> 
> Perhaps we could provide frange::contains_zero_p ()?

Well, contains_p in irange is a method on the value range, while here we don't
have a frange, but just naked REAL_VALUE_TYPEs.
It is twice contains_zero_p...
> 
> +    // +-0.0 / +-0.0 or +-INF / +-INF is a known NAN.
> +    if ((real_iszero (&lh_lb)
> +	 && real_iszero (&lh_ub)
> +	 && real_iszero (&rh_lb)
> +	 && real_iszero (&rh_ub))
> 
> This looks like frange::contains_zerp_p () as well.

No, this is twice zero_p.  Due to signed zeros it isn't a singleton +
contains_zero_p, just both boundaries are zero.

> +	|| (real_isinf (&lh_lb)
> +	    && real_isinf (&lh_ub, real_isneg (&lh_lb))
> +	    && real_isinf (&rh_lb)
> +	    && real_isinf (&rh_ub, real_isneg (&rh_lb))))
> 
> Note that, real_isinf with only one argument checks for +-INF.

I know.  I'm intentionally using one and 2 argument ones to verify
that lh is either [INF,INF] or [-INF,-INF], but not [-INF,INF].

>  But I think
> what you're looking for is frange::maybe_isinf.

Again, that works on frange, which I don't have here.
> 
> Could your patch be simplified with some of these?
> 
>   // fpclassify like API
>   bool known_isfinite () const;
>   bool known_isnan () const;
>   bool known_isinf () const;
>   bool maybe_isnan () const;
>   bool maybe_isnan (bool sign) const;
>   bool maybe_isinf () const;
>   bool signbit_p (bool &signbit) const;
>   bool nan_signbit_p (bool &signbit) const;
> 
> We should ultimately avoid peeking at the end points unnecessarily in order
> to prepare ourselves for next release when we (hopefully) have sub-ranges.

No, see above (at least for now).  The peeking at the end points is needed
because those end points behave weirdly.