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

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

Joel Brobecker wrote:
> Eli Zaretskii wrote:
> > 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.
> 
> FWIW, I'm receptive to the fact that using native FP is indeed
> a sure way to make sure we have the same behavior in GDB and
> in the program. But on the other hand, we have to be careful
> about the impact on code complexity. If having that functionality
> makes the code harder to implement and maintain past a certain
> degree, then I think it is OK to break the assumption, if there
> was any, that GDB would perform the FP operation exactly the same
> as on the host.
> 
> Performance is a non-aspect to me: We not doing millions of
> these operations in a row. In the vast majority of situations,
> it'll be a handful. Even if it MPFR cannot be as fast as
> hardware, operations were timed to be less than a microsecond
> for the common operations to a 100 digits, and with a couple
> of exceptions where it takes about about 40 micro seconds to
> compute to 100 digits, the rest is clocked at about 5-10 microseconds
> per operation up to 100 digits.
> http://www.mpfr.org/mpfr-3.1.0/timings.html

I've just posted an updated set of patches that implements the
suggestion to use host FP if the format matches, and MPFR if not.
To keep code complexity down, this is done by encapsulating the
operations in an abstract base class with multiple implementations.
https://sourceware.org/ml/gdb-patches/2017-11/msg00323.html
https://sourceware.org/ml/gdb-patches/2017-11/msg00324.html

Does this address your concerns?  Any further comments welcome!

Bye,
Ulrich

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