On Tue, Sep 6, 2022 at 2:17 PM Richard Biener
<richard.guent...@gmail.com> wrote:
>
> On Tue, Sep 6, 2022 at 2:06 PM Jakub Jelinek <ja...@redhat.com> wrote:
> >
> > On Tue, Sep 06, 2022 at 01:47:43PM +0200, Aldy Hernandez wrote:
> > > Question...for !HONOR_NANS or !HONOR_INFINITIES or whatever, say the
> > > range for the domain is [-MIN, +MAX] for the min and max representable
> > > numbers. What happens for MAX+1? Is that undefined? I wonder what
> > > real.cc does for that.
> >
> > I'm afraid I have no idea.
> >
> > The formats without Inf/NaN are:
> > spu_single_format
> > vax_{f,d,g}_format
> > arm_half_format
> >
> > Never had the "pleasure" to work with any of these.
> > Looking at encode_vax_*, it seems both GCC internal inf and nan are
> > most likely are encoded as maximum or minimum representable numbers
> > (depending on sign), and encode_ieee_half for !fmt->has_inf does too
> > (for !fmt->has_nans it seems to "encode" the nan mantissa bits into
> > highest possible exponent). encode_ieee_single (for spu) uses
> > maximum or minimum representable numbers for any infinities or nans.
> > What they actually do at runtime is something I can't really check,
> > but one would hope it is saturating...
>
> I'd simply do what we do for -ffinite-math-only - just pretend you don't
> cross the maximum/minmum value and effectively saturate the range.
Yeah, that sounds reasonable. I take it I can assume that MAX+1 is
undefined for -ffinite-math-only? So I'm free to saturate, etc?
Ok, crazy hypothetical talk...
if (x > y)
For -ffinite-math-only, on the true side, can I assume:
x: MIN + 1 ULP
y: MAX - 1 ULP
range-op for integers did all sorts of stuff like that, and we ended
up optimizing some interesting cases...as well as driving the middle
end warnings crazy :-P.
Aldy
