Re: [RFC][00/19] Target FP: Precise target floating-point emulation

["Ulrich Weigand" <uweigand@de.ibm.com>]

Eli Zaretskii wrote:
> > Date: Tue, 5 Sep 2017 20:20:30 +0200 (CEST)
> > From: "Ulrich Weigand" <uweigand@de.ibm.com>
> > 
> > This patch series addresses this problem by converting GDB to perform
> > all floating-operations by precisely emulation target arithmetic,
> > using the MPFR library.
> 
> In native debugging as well?

Currently, yes.  However, this can be fine-tuned as we like using the
new setup; we could fall back to host arithmetic in some cases.

Making that decision based on native vs. remote debugging does not
appear to be the correct choice here, in particular given the problems
pointed out in my original mail with *native* debugging if FP types
larger than "long double" are used (like __float128).

However, we could make a decision based on the particular target
*format* (e.g. whether it is equivalent to one of the available
host formats).  The question is whether this is worthwhile the
additional complication of code (and possibly test cases).

> If so, wouldn't that make GDB significantly slower in that case?

Of course, considering just one single arithmetic operation, a call
to MPFR is orders of magnitude slower than just doing the operation
in host format (often a single instruction).

But that is not the only question; the other question is how frequent
those operations are in the first place.  And from what I can tell,
all the "hot", performance critical paths in GDB do not perform any
FP operations at all in the first place.  Those are only done in
response to UI actions specifically involving FP values.

For example, the whole of the gdb.base test suite appears to be doing
less 100 instances of any base FP operation.  (This does not count FP
parsing or printing, which are a bit more frequent -- but for those
operations the performance difference between a native printf/scanf
and the corrsponding MPFR printf/scanf is much less in proportion.)
So there is no overall wall-clock performance difference visible.

Now, I'm sure one can construct cases where FP arithmetic operations
occur much more frequently -- but I'd prefer to see a case where it
actually matters in real life before deciding to implement the more
complicated solution described above.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com