From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93767 invoked by alias); 6 Sep 2017 21:04:54 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 93079 invoked by uid 89); 6 Sep 2017 21:04:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=life, millions, sum X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 06 Sep 2017 21:04:48 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 525B756498; Wed, 6 Sep 2017 17:04:46 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tIN2h-ULNsyo; Wed, 6 Sep 2017 17:04:46 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 1EC7B56497; Wed, 6 Sep 2017 17:04:46 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 648D289FA5; Wed, 6 Sep 2017 14:04:44 -0700 (PDT) Date: Wed, 06 Sep 2017 21:04:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: Ulrich Weigand , gdb-patches@sourceware.org Subject: Re: [RFC][00/19] Target FP: Precise target floating-point emulation Message-ID: <20170906210444.wk4xhl7qiqr4ubdb@adacore.com> References: <20170906180051.53811D83591@oc3748833570.ibm.com> <83d1731xoi.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83d1731xoi.fsf@gnu.org> User-Agent: NeoMutt/20170113 (1.7.2) X-SW-Source: 2017-09/txt/msg00172.txt.bz2 > 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