[Bug tree-optimization/24021] VRP does not work with floating points

["amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #12 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Aldy Hernandez from comment #8)
> (In reply to Jeffrey A. Law from comment #7)
> > Very cool.  ANd no, I'm not enough of an expert on the FP side to shepherd
> > that though.  I would expect it to be exceptionally tricky on the solver
> > side.
> 
> The solver, or ranger/gori, should be isolated from changes.  The main goal
> is to make ranger work with generic vrange's, not iranges or franges.  Once
> I'm done with the abstraction, it should only be value-range.* (class
> frange) and range-ops* that should be affected.  That's the theory anyhow
> ;-).

Yeah, once we get things in place, there will be a skeleton frange class
representation that does some set of basic operations.

One or more floating point experts are welcome then to flush out additional
representational requirements in the frange class and range-op implementations
of any tree-codes operations.   There shouldn't be any changed required
anywhere else. VRP/threader/relations/folding/etc are all driven by range-ops.

And we are of course happy to help when the time comes and GCC13 opens up and
the abstraction code goes in.  If someone is really keen, they may be able to
work on a development branch a bit earlier than that... 

I also have a short list of practical floating point considerations I collected
a couple of years ago. So I don't lose it:

finite
non-zero/positive/negative
normalized
in the range [-1,1] (for trig functions)
which I would expect to come from adding some domain/range knowledge from
standard math functions, and propagating range info from integer stuff from
which floating point values are derived, on top of the usual stuff.

e.g. in embedded world floating-point values from peripherals would commonly
come from some PWM feature via integer division by a constant denominator,
which could tell us a fair bit (even more if it could use builtin expect
information about the numerator).

as far as existing consumers for this info - I'm not sure if glibc still has
special finite versions of functions, but those could be used based on range
info. likewise, knowing a value is normal or in a bounded range could allow for
'relaxed' versions of library functions to be used. there should also be some
inline sequences or other code transforms that are controlled by
finite-math-only and also enabled for provably finite values.