Message ID | 20220905134701.3330685-1-aldyh@redhat.com |
---|---|
State | New |
Headers | show |
Series | Decimal floats can never be an frange::singleton_p. | expand |
On Mon, Sep 05, 2022 at 03:47:01PM +0200, Aldy Hernandez wrote: > As Jakub mentioned in the PR, because many numbers have multiple > possible representations, we can't reliably return true here. > > I'll commit this if tests pass. > > I wonder if its worth even handling decimal floats in frange, since > there's a lot of things we can't represent. I suppose even though we > could never propagate an actual value with VRP, we could fold > conditionals (symbolic and stuff outside ranges, etc) ??. > > Thoughts? > > PR middle-end/106831 > > gcc/ChangeLog: > > * value-range.cc (frange::singleton_p): Return false for > DECIMAL_FLOAT_TYPE_P. > --- > gcc/value-range.cc | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/gcc/value-range.cc b/gcc/value-range.cc > index c3f668a811a..12a3750d078 100644 > --- a/gcc/value-range.cc > +++ b/gcc/value-range.cc > @@ -647,6 +647,14 @@ frange::singleton_p (tree *result) const > if (HONOR_NANS (m_type) && !get_nan ().no_p ()) > return false; > > + // Because the significand is not normalized (there is no > + // implicit leading "1"). Most values with less than 7 > + // significant digits have multiple possible representations. > + // Zero has 192 possible representations (or twice that for > + // signed zeros). The exact details (7, 192) are dependent on the format, for decimal64 it is (16, 768) and for decimal128 (34, 12288). Jakub
Final version of the patch. Disable frange for DECIMAL_FLOAT_MODE_P altogether. Tested on x86-64 Linux with regstrap as well as mpfr tests. On Mon, Sep 5, 2022 at 3:47 PM Aldy Hernandez <aldyh@redhat.com> wrote: > > As Jakub mentioned in the PR, because many numbers have multiple > possible representations, we can't reliably return true here. > > I'll commit this if tests pass. > > I wonder if its worth even handling decimal floats in frange, since > there's a lot of things we can't represent. I suppose even though we > could never propagate an actual value with VRP, we could fold > conditionals (symbolic and stuff outside ranges, etc) ??. > > Thoughts? > > PR middle-end/106831 > > gcc/ChangeLog: > > * value-range.cc (frange::singleton_p): Return false for > DECIMAL_FLOAT_TYPE_P. > --- > gcc/value-range.cc | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/gcc/value-range.cc b/gcc/value-range.cc > index c3f668a811a..12a3750d078 100644 > --- a/gcc/value-range.cc > +++ b/gcc/value-range.cc > @@ -647,6 +647,14 @@ frange::singleton_p (tree *result) const > if (HONOR_NANS (m_type) && !get_nan ().no_p ()) > return false; > > + // Because the significand is not normalized (there is no > + // implicit leading "1"). Most values with less than 7 > + // significant digits have multiple possible representations. > + // Zero has 192 possible representations (or twice that for > + // signed zeros). > + if (DECIMAL_FLOAT_TYPE_P (m_type)) > + return false; > + > // Return the appropriate zero if known. > if (HONOR_SIGNED_ZEROS (m_type) && zero_p ()) > { > -- > 2.37.1 >
diff --git a/gcc/value-range.cc b/gcc/value-range.cc index c3f668a811a..12a3750d078 100644 --- a/gcc/value-range.cc +++ b/gcc/value-range.cc @@ -647,6 +647,14 @@ frange::singleton_p (tree *result) const if (HONOR_NANS (m_type) && !get_nan ().no_p ()) return false; + // Because the significand is not normalized (there is no + // implicit leading "1"). Most values with less than 7 + // significant digits have multiple possible representations. + // Zero has 192 possible representations (or twice that for + // signed zeros). + if (DECIMAL_FLOAT_TYPE_P (m_type)) + return false; + // Return the appropriate zero if known. if (HONOR_SIGNED_ZEROS (m_type) && zero_p ()) {