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

[Eli Zaretskii <eliz at gnu dot org>]

> Date: Wed, 6 Sep 2017 20:00:51 +0200 (CEST)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
> Cc: gdb-patches@sourceware.org
> 
> > > 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.

I'm sorry, but it doesn't feel right to me to slow down native
operations where they fit the bill.  I agree that native debugging
which manipulates FP data types not supported natively could or should
be emulated, but normal 'float', 'double', and 'long double' types
should IMO use native FP processing.  Besides the speed issue, that's
also the only practical way to make sure these operations are _always_
identical to what the debuggee's code does or will do.

> 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.

I'm sorry, but slowing down GDB just because there's no evidence
someone needs the fast operation is not a good idea IMO.  We should
make GDB as fast as it can be regardless of any particular examples of
the need for a fast GDB.

In sum, I'm in favor of having MPFR support where native FP
calculations cannot be used or don't represent the target correctly,
but not where they can and do.

Thanks.