From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21115 invoked by alias); 19 Aug 2019 14:43:14 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 21106 invoked by uid 89); 19 Aug 2019 14:43:13 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT autolearn=no version=3.3.1 spammy=complications, H*i:sk:CACMrGj, fp_int_*, FP_INT_* X-HELO: esa4.mentor.iphmx.com Received: from esa4.mentor.iphmx.com (HELO esa4.mentor.iphmx.com) (68.232.137.252) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Aug 2019 14:43:12 +0000 IronPort-SDR: or9oOw+uiiAiJ1eLD9NmxGtaNuitF17xUZFKoBgzM+NFi35b8wrZ4DmSRjeRdI931TWomyVW/p 3c8+wxEnLSalDNqe+P9QpvyjzqTsfPenTDq3WndIgos3L8rFur9QoUA9xo+aHk8cSrpK5nE0jw ocxy18tZl7yy16qV+gswLOvGd43n9qbl6CdAh5sOUWZSbxDmnN8jUXYLfGD3MIuZFzBlkbLkVM UTvvUPzQthL4fLO9OH0u75/OKfiiExOCC+h39Khxfbsvq5g4DA6ZmLqzxHT+8oVvvKU0GDviph nCY= Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 19 Aug 2019 06:43:11 -0800 IronPort-SDR: rNcJcTcmO3bWpjAYb2Jd49QKjfj9CIoWFfC7TMadx35nUspnWIHRFRaEK8DGuyB3EJaE8iCbyH TPOiTjVY4wec457+gfys3Pc6knM4P6cgzdp/HDEtRapJGRejJKfZQBQ1Scski5JuMoaUkXcWr5 p5uDlf7xNO8oyKDtV0VMCQXO6+vfXxxO8Pp+lF0DrrgLalY1LvZHRPunzLtlp4OnpFSnnyu5h4 T/OKQUqEJLc3ZtM6/cRrlBj5JFLN9K9e67VM6ZHEfD9WED4BVQKULjGIfbBk3z2tedNJCrTBtV ox8= Date: Mon, 19 Aug 2019 14:43:00 -0000 From: Joseph Myers To: Tejas Joshi CC: , Martin Jambor , Subject: Re: [GSoC-19] Expanding fromfp variants on AArch64 In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Return-Path: joseph@codesourcery.com X-SW-Source: 2019-08/txt/msg00140.txt.bz2 On Mon, 19 Aug 2019, Tejas Joshi wrote: > How can I add a target hook to specify the FP_INT_* values from libm ? See target.def. You'll need a GCC-specific enum (GCC_FP_INT_*, say) that GCC uses internally, and a hook that maps between that and FP_INT_*. I'm guessing that for the likely uses, maybe the hook should map from FP_INT_* to GCC_FP_INT_* (so it gets used on constant arguments to the built-in function to say which rounding direction they are in GCC's internal enum). It will need to be able to return that a constant doesn't map to a known rounding mode (not an error, just means that call can't be expanded inline or optimized to a constant). Then the relevant macro giving the default for glibc systems should be defined in config/gnu-user.h (see how it defines e.g. TARGET_LIBC_HAS_FUNCTION). > Also as this includes rounding to integers, does it involve any RTL > related complications that we have encountered in FADD ? The new RTL would effectively be variants of the fix_trunc and fixuns_trunc patterns, which can use (fix) and (unsigned_fix) RTL; the new variants would take an argument in a floating-point mode, returning one in an integer mode - but with extra information involved about the number of bits, rounding direction, handling of "inexact". fix_trunc and fixuns_trunc / (fix) and (unsigned_fix) always use FP_INT_TOWARDZERO, always use the width of the mode and have unspecified "inexact" handling for non-integer in-range values (they correspond to C casts) so are not themselves suitable for implementing the new built-in functions (but the particular instructions those patterns expand to are likely to be suitable for certain arguments to certain of the new built-in functions). -- Joseph S. Myers joseph@codesourcery.com