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

[Joel Brobecker <brobecker at adacore dot com>]

> 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

-- 
Joel