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.
