From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 61635 invoked by alias); 16 Nov 2017 19:06:13 -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 61619 invoked by uid 89); 16 Nov 2017 19:06:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=5-10, brobecker, Brobecker, Hx-languages-length:2850 X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 16 Nov 2017 19:06:10 +0000 Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAGJ67iI127733 for ; Thu, 16 Nov 2017 14:06:08 -0500 Received: from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109]) by mx0b-001b2d01.pphosted.com with ESMTP id 2e9etu5sed-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 16 Nov 2017 14:06:07 -0500 Received: from localhost by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 16 Nov 2017 19:06:03 -0000 Received: from b06cxnps3074.portsmouth.uk.ibm.com (9.149.109.194) by e06smtp13.uk.ibm.com (192.168.101.143) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 16 Nov 2017 19:06:00 -0000 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id vAGJ60dA38141996; Thu, 16 Nov 2017 19:06:00 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 95AE95204E; Thu, 16 Nov 2017 17:59:39 +0000 (GMT) Received: from oc3748833570.ibm.com (unknown [9.152.213.29]) by d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTP id 83BDE5204C; Thu, 16 Nov 2017 17:59:39 +0000 (GMT) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id E8191D800CB; Thu, 16 Nov 2017 20:05:59 +0100 (CET) Subject: Re: [RFC][00/19] Target FP: Precise target floating-point emulation To: brobecker@adacore.com (Joel Brobecker) Date: Thu, 16 Nov 2017 19:06:00 -0000 From: "Ulrich Weigand" Cc: eliz@gnu.org (Eli Zaretskii), gdb-patches@sourceware.org In-Reply-To: <20170906210444.wk4xhl7qiqr4ubdb@adacore.com> from "Joel Brobecker" at Sep 06, 2017 02:04:44 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17111619-0012-0000-0000-0000058E3449 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17111619-0013-0000-0000-00001908F786 Message-Id: <20171116190559.E8191D800CB@oc3748833570.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-11-16_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711160254 X-SW-Source: 2017-11/txt/msg00325.txt.bz2 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