public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <jeffreyalaw@gmail.com>
To: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] frange: dump hex values when dumping FP numbers.
Date: Thu, 22 Sep 2022 13:25:28 -0600	[thread overview]
Message-ID: <71cf6e17-40a1-962e-8288-8258abe2b2bd@gmail.com> (raw)
In-Reply-To: <20220922164911.2566143-1-aldyh@redhat.com>


On 9/22/22 10:49, Aldy Hernandez via Gcc-patches 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)?
>
> 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.

The big advantage of the hex representation is you can feed that back 
into the compiler trivially and be confident the bit pattern hasn't 
changed.   I've found it invaluable when doing deep FP analysis.


jeff



  parent reply	other threads:[~2022-09-22 19:25 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 [this message]
2022-09-22 21:04 ` Jakub Jelinek
2022-09-23  6:56   ` Aldy Hernandez

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=71cf6e17-40a1-962e-8288-8258abe2b2bd@gmail.com \
    --to=jeffreyalaw@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    /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).