public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Aldy Hernandez <aldyh@redhat.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: GCC patches <gcc-patches@gcc.gnu.org>,
	Richard Biener <richard.guenther@gmail.com>,
	 Andrew MacLeod <amacleod@redhat.com>
Subject: Re: [PATCH] frange: dump hex values when dumping FP numbers.
Date: Fri, 23 Sep 2022 08:56:32 +0200	[thread overview]
Message-ID: <CAGm3qMVGWHZ2wx9JPrB5-YD-SP0EtFaKT061jbTrRBvaD4b3iw@mail.gmail.com> (raw)
In-Reply-To: <YyzN2XphM4ZuvgYh@tucnak>

[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]

On Thu, Sep 22, 2022 at 11:04 PM Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Thu, Sep 22, 2022 at 06:49:10PM +0200, Aldy Hernandez wrote:
> > It has been suggested that if we start bumping numbers by an ULP when
> > calculating open ranges (for example the numbers less than 3.0) that
> > dumping these will become increasingly harder to read, and instead we
> > should opt for the hex representation.  I still find the floating
> > point representation easier to read for most numbers, but perhaps we
> > could have both?
> >
> > With this patch this is the representation for [15.0, 20.0]:
> >
> >      [frange] float [1.5e+1 (0x0.fp+4), 2.0e+1 (0x0.ap+5)]
> >
> > Would you find this useful, or should we stick to the hex
> > representation only (or something altogether different)?
>
> I think dumping both is the way to go, but real_to_hexadecimal doesn't
> do anything useful with decimal floats, so that part should be
> guarded on !DECIMAL_FLOAT_TYPE_P (type).

Remember that decimal floats are not supported for frange, but I
suppose it's good form to guard the print for when we do.

>
> Why do you build a tree + dump_generic_node for decimal instead of
> real_to_decimal_for_mode ?

Honestly, cause I was too lazy.  That code is inherited from irange
and I figured it's just a dumping routine, but I'm happy to fix it.

> The former I think calls:
>             char string[100];
>             real_to_decimal (string, &d, sizeof (string), 0, 1);
> so perhaps:
>   char s[100];
>   real_to_decimal_for_mode (s, &r, sizeof (string), 0, 1, TYPE_MODE (type));
>   pp_string (pp, "%s", s);
>   if (!DECIMAL_FLOAT_TYPE_P (type))
>     {
>       real_to_hexadecimal (s, &r, sizeof (s), 0, 1);
>       pp_printf (pp, " (%s)", s);
>     }
> ?

Thanks.

I'm retesting the following and will commit if it succeeds since we
seem to have overwhelming consensus :).
Aldy

[-- Attachment #2: 0001-frange-dump-hex-values-when-dumping-FP-numbers.patch --]
[-- Type: text/x-patch, Size: 2834 bytes --]

From 2f052904412bbe5821ee310067ad76b52980d8e3 Mon Sep 17 00:00:00 2001
From: Aldy Hernandez <aldyh@redhat.com>
Date: Thu, 22 Sep 2022 18:07:03 +0200
Subject: [PATCH] frange: dump hex values when dumping FP numbers.

It has been suggested that if we start bumping numbers by an ULP when
calculating open ranges (for example the numbers less than 3.0) that
dumping these will become increasingly harder to read, and instead we
should opt for the hex representation.  I still find the floating
point representation easier to read for most numbers, but perhaps we
could have both?

With this patch this is the representation for [15.0, 20.0]:

     [frange] float [1.5e+1 (0x0.fp+4), 2.0e+1 (0x0.ap+5)]

Would you find this useful, or should we stick to the hex
representation only?

Tested on x86-64 Linux.

gcc/ChangeLog:

	* value-range-pretty-print.cc (vrange_printer::print_real_value): New.
	(vrange_printer::visit): Call print_real_value.
	* value-range-pretty-print.h: New print_real_value.
---
 gcc/value-range-pretty-print.cc | 19 +++++++++++++++----
 gcc/value-range-pretty-print.h  |  1 +
 2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/gcc/value-range-pretty-print.cc b/gcc/value-range-pretty-print.cc
index eb7442229ba..8cbe97b76fd 100644
--- a/gcc/value-range-pretty-print.cc
+++ b/gcc/value-range-pretty-print.cc
@@ -117,6 +117,19 @@ vrange_printer::print_irange_bitmasks (const irange &r) const
   pp_string (pp, buf);
 }
 
+void
+vrange_printer::print_real_value (tree type, const REAL_VALUE_TYPE &r) const
+{
+  char s[100];
+  real_to_decimal_for_mode (s, &r, sizeof (s), 0, 1, TYPE_MODE (type));
+  pp_string (pp, s);
+  if (!DECIMAL_FLOAT_TYPE_P (type))
+    {
+      real_to_hexadecimal (s, &r, sizeof (s), 0, 1);
+      pp_printf (pp, " (%s)", s);
+    }
+}
+
 // Print an frange.
 
 void
@@ -141,11 +154,9 @@ vrange_printer::visit (const frange &r) const
   bool has_endpoints = !r.known_isnan ();
   if (has_endpoints)
     {
-      dump_generic_node (pp,
-			 build_real (type, r.lower_bound ()), 0, TDF_NONE, false);
+      print_real_value (type, r.lower_bound ());
       pp_string (pp, ", ");
-      dump_generic_node (pp,
-			 build_real (type, r.upper_bound ()), 0, TDF_NONE, false);
+      print_real_value (type, r.upper_bound ());
     }
   pp_character (pp, ']');
   print_frange_nan (r);
diff --git a/gcc/value-range-pretty-print.h b/gcc/value-range-pretty-print.h
index 20c26598fe7..a9ae5a7b4cc 100644
--- a/gcc/value-range-pretty-print.h
+++ b/gcc/value-range-pretty-print.h
@@ -32,6 +32,7 @@ private:
   void print_irange_bound (const wide_int &w, tree type) const;
   void print_irange_bitmasks (const irange &) const;
   void print_frange_nan (const frange &) const;
+  void print_real_value (tree type, const REAL_VALUE_TYPE &r) const;
 
   pretty_printer *pp;
 };
-- 
2.37.1


      reply	other threads:[~2022-09-23  6:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-22 16:49 Aldy Hernandez
2022-09-22 16:49 ` [PATCH] frange: drop endpoints to min/max representable numbers for -ffinite-math-only Aldy Hernandez
2022-09-23  7:03   ` Richard Biener
2022-09-23  7:21     ` Aldy Hernandez
2022-09-23  7:51       ` Richard Biener
2022-09-22 19:23 ` [PATCH] frange: dump hex values when dumping FP numbers Toon Moene
2022-09-22 19:25 ` Jeff Law
2022-09-22 21:04 ` Jakub Jelinek
2022-09-23  6:56   ` Aldy Hernandez [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGm3qMVGWHZ2wx9JPrB5-YD-SP0EtFaKT061jbTrRBvaD4b3iw@mail.gmail.com \
    --to=aldyh@redhat.com \
    --cc=amacleod@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=richard.guenther@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).