On Fri, Mar 18, 2022 at 5:01 PM Jeff Law <jeffreya...@gmail.com> wrote:
>
>
>
> On 3/18/2022 7:16 AM, Andrew MacLeod wrote:
> > On 3/17/22 19:27, Jeff Law via Gcc-patches wrote:
> >>
> >> On 3/15/2022 2:03 AM, Roger Sayle wrote:
> >>>> -----Original Message-----
> >>>> From: Richard Biener <richard.guent...@gmail.com>
> >>>> Sent: 15 March 2022 07:29
> >>>> To: Roger Sayle <ro...@nextmovesoftware.com>
> >>>> Cc: GCC Patches <gcc-patches@gcc.gnu.org>
> >>>> Subject: Re: [PATCH] Ignore (possible) signed zeros in operands of FP
> >>>> comparisons.
> >>>>
> >>>> On Mon, Mar 14, 2022 at 8:26 PM Roger Sayle
> >>>> <ro...@nextmovesoftware.com> wrote:
> >>>>>
> >>>>> I've been wondering about the possible
> >>>>> performance/missed-optimization
> >>>>> impact of my patch for PR middle-end/98420 and similar IEEE
> >>>>> correctness fixes that disable constant folding optimizations when
> >>>>> worrying
> >>>> about -0.0.
> >>>>> In the common situation where the floating point result is used by a
> >>>>> FP comparison, there's no distinction between +0.0 and -0.0, so some
> >>>>> HONOR_SIGNED_ZEROS optimizations that we'd usually disable, are safe.
> >>>>>
> >>>>> Consider the following interesting example:
> >>>>>
> >>>>> int foo(int x, double y) {
> >>>>> return (x * 0.0) < y;
> >>>>> }
> >>>>>
> >>>>> Although we know that x (when converted to double) can't be NaN or
> >>>>> Inf, we still worry that for negative values of x that (x * 0.0) may
> >>>>> be -0.0 and so perform the multiplication at run-time. But in this
> >>>>> case, the result of the comparison (-0.0 < y) will be exactly the
> >>>>> same
> >>>>> as (+0.0 < y) for any y, hence the above may be safely constant
> >>>>> folded to "0.0 <
> >>>> y"
> >>>>> avoiding the multiplication at run-time.
> >
> > I'm going to hazard a guess that this can be handled in the upcoming
> > floating point range support? there was a start of a conversation in
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021 about a month ago.
> >
> > I know *zero* about floating point, but It seems like when we track
> > floating point ranges, we will naturally be able to integrate
> >
> > _2 = _1 * 0.0;
> > _3 = _2 < y_5(D);
> >
> > that _2 evaluates to +/- 0.0 and when we do look at (_2 < y_5)
> > that VRP can simplify that to 0.0 < y? (or any patch which uses
> > simplification and ranges). It seems like it should be
> > straightforward anyway.
Yes, definitely. Ranger is really a propagation engine. The plan all
along was to make it type agnostic with a generic vrange class that
provides core functionality that each implementation overrides (union,
intersect, varying, undefined, etc). Right now we have plans for
float ranges, pointer tracking, and eventually string tracking. The
generic vrange abstraction is done and queued up for the next release.
I have a core float implementation that handles relationals and end
points, but the plan is to add bits to track nonzero, infs, nans, etc.
Since ranger will just be a propagation engine, range-ops, union,
intersection, etc, could propagate not NaN and non Inf for the cast
operator above, plus +-0.0 for _2. The float range-op entries would
be able to do all sorts of magic by querying the range for _2. Also
the simplify_using_ranges class vrp uses could simplify the _2 < y_5
with appropriate smarts.
It really does seem pretty straightforward once the vrange and frange
classes are in place. All this should be doable for the next stage1,
but we could use help with the nuances of frange when the time comes.
> Yea, I guess we'd pick it up that way and that's probably cleaner than
> what I was originally thinking in this space.
>
> We realize that 2 is +-0.0. Then we realize that for the comparison, we
> can constant propagate +0.0 for _2 since +0.0 and -0.0 behave the same
> way. Ideally that removes the last reference to _2 and we DCE away the
> multiplication.
Yup yup.
Aldy
>
>
> jeff
>
