From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39550 invoked by alias); 3 Mar 2020 16:22:15 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 39536 invoked by uid 89); 3 Mar 2020 16:22:14 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:938 X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.110.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 03 Mar 2020 16:22:13 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9BA552F; Tue, 3 Mar 2020 08:22:11 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0C3BD3F6C4; Tue, 3 Mar 2020 08:22:10 -0800 (PST) From: Richard Sandiford To: Wilco Dijkstra Mail-Followup-To: Wilco Dijkstra ,Bu Le , gcc-help , richard.sandiford@arm.com Cc: Bu Le , gcc-help Subject: Re: [AArch64][Spec2017]Question about mlow-precision-div optimization. References: Date: Tue, 03 Mar 2020 16:22:00 -0000 In-Reply-To: (Wilco Dijkstra's message of "Thu, 27 Feb 2020 17:01:52 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2020-03/txt/msg00012.txt Wilco Dijkstra writes: >> And do you think it worth us providing a parameter to alter the iteration so that the >> accuracy can be a trade-off of speed. > > What do you mean? We already have -mlow-precision-div (and -sqrt/-recip-sqrt). The suggestion was to have a parameter to control the number of steps, rather than always use the values that are currently hard-coded into aarch64.c. That sounds OK in principle. It would fix one of the downsides of the current code, in which users can force reciprocal approximation to be used at low precision, but can't force it to be used at the precisions normally chosen by -mtune. It's probably not worth promoting to a full -m option that in theory would be supported for evermore. But now that targets can define their own --params, it might make sense to use --params here. Thanks, Richard