From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) by sourceware.org (Postfix) with ESMTPS id E06B43858D37 for ; Wed, 30 Sep 2020 12:23:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E06B43858D37 Received: by mail-ed1-x542.google.com with SMTP id j2so1590343eds.9 for ; Wed, 30 Sep 2020 05:23:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jhNFkkvQuV2CB68e9XqgwGRbWpUfNlRBusL+aSAwnvk=; b=I+/5vpUbt5UyaPL0KMLdk4rdmIwhizx+NY5JHAveiabfIyTS5WJct5RRC1z8pW5/kD c88iPHmNo12IxcYHD9j9zF3lD7TYq9dwELgsaIv3VcjeRX0q++zVJB5mk0RYQqGyhU5z 8yO/EEb+IaTP8A22pS9iBEkj/vKDexU0EkBDzFekKYw4ctft/AKOLcISY/nVnioc2/on 6do2X1ZgUhRLhaGft7tycKI9ySd2I+9R+gsux4mwHPeA+B8N92JT4egqihGwRNlKNdZ3 6jXAez8/AOeihPbglkVgQAzhPkQX6B063nSVXZ+PI/LIzXj0QenmqfpfagE6NoH0rFNV jULA== X-Gm-Message-State: AOAM530b0GffnUQTAlrC1rNEm1iXjenVO1wVCdEkbYdIY3O9FHsIwi/u m2xnX0rYL/ouU5rJ+4mg1+TnpUmaU12JqaU51Ks= X-Google-Smtp-Source: ABdhPJxzXLWoUXk5Ryp7+o2ik1NZYVqhcp///y5lFikYNJ8J9SYpIcQ+y/H6QBM8uicnXBiVRArm3bWRmn7fFxFZUK4= X-Received: by 2002:a50:84a2:: with SMTP id 31mr2502873edq.138.1601468610948; Wed, 30 Sep 2020 05:23:30 -0700 (PDT) MIME-Version: 1.0 References: <39b3a842-46d8-95ef-a2d8-4de7d3060bc1@suse.de> <50b29d36-6268-e1ea-efec-fd3e254c7d7d@suse.de> In-Reply-To: <50b29d36-6268-e1ea-efec-fd3e254c7d7d@suse.de> From: Richard Biener Date: Wed, 30 Sep 2020 14:23:20 +0200 Message-ID: Subject: Re: [PATCH] Add type arg to TARGET_LIBC_HAS_FUNCTION To: Tom de Vries Cc: gcc-patches , Tobias Burnus Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 12:23:33 -0000 On Tue, Sep 29, 2020 at 2:18 PM Tom de Vries wrote: > > On 9/29/20 8:59 AM, Richard Biener wrote: > > On Mon, Sep 28, 2020 at 7:28 PM Tom de Vries wrote: > >> > >> [ was: Re: [Patch][nvptx] return true in libc_has_function for > >> function_sincos ] > >> > >> On 9/26/20 6:47 PM, Tobias Burnus wrote: > >>> Found when looking at PR97203 (but having no effect there). > >>> > >>> The GCC ME optimizes with -O1 (or higher) the > >>> a = sinf(x) > >>> b = cosf(x) > >>> to __builtin_cexpi(x, &a, &b) > >>> (...i as in internal; like cexp(z) but with with __real__ z == 0) > >>> > >>> > >>> In expand_builtin_cexpi, that is handles as: > >>> if (optab_handler (sincos_optab, mode) != CODE_FOR_nothing) > >>> ... > >>> else if (targetm.libc_has_function (function_sincos)) > >>> ... > >>> else > >>> fn = builtin_decl_explicit (BUILT_IN_CEXPF); > >>> > >>> And the latter is done. As newlib's cexpf does not know that > >>> __real__ z == 0, it calculates 'r = expf (__real__ z)' before > >>> invoking sinf and cosf on __imag__ z. > >>> > >>> Thus, it is much faster to call 'sincosf', which also exists > >>> in newlib. > >>> > >>> Solution: Return true for targetm.libc_has_function (function_sincos). > >>> > >>> > >>> NOTE: With -funsafe-math-optimizations (-O0 or higher), > >>> sinf/cosf and sincosf invoke .sin.approx/.cos/.approx instead of > >>> doing a library call. > >> > >> This version takes care to enable sincos and sincosf, but not sincosl. > >> > >> Target hook changes OK for trunk? > > > > @@ -9770,7 +9770,7 @@ fold_builtin_sincos (location_t loc, > > } > > if (!call) > > { > > - if (!targetm.libc_has_function (function_c99_math_complex) > > + if (!targetm.libc_has_function (function_c99_math_complex, NULL_TREE) > > > > why pass NULL_TREE and not 'type' here? > > > > || !builtin_decl_implicit_p (fn)) > > return NULL_TREE; > > > > I was trying to do the minimal, sincos-only implementation. > > > similar for the builtins.def change for the cases where math functions > > are affected? I guess it's a bit awkward to make it work there, so OK. > > > > bool > > -darwin_libc_has_function (enum function_class fn_class) > > +darwin_libc_has_function (enum function_class fn_class, tree type) > > { > > - if (fn_class == function_sincos) > > + if (type != NULL_TREE) > > + { > > + switch (fn_class) > > + { > > + case function_sincos: > > + break; > > + default: > > + /* Not implemented. */ > > + gcc_unreachable (); > > + } > > + } > > > > huh. I think special-casing this just for sincos is a bit awkward, > > esp. ICEing for other queries with a type. Specifically > > > > -@deftypefn {Target Hook} bool TARGET_LIBC_HAS_FUNCTION (enum > > function_class @var{fn_class}) > > +@deftypefn {Target Hook} bool TARGET_LIBC_HAS_FUNCTION (enum > > function_class @var{fn_class}, tree @var{type}) > > This hook determines whether a function from a class of functions > > -@var{fn_class} is present in the target C library. > > +@var{fn_class} is present in the target C library. The @var{type} argument > > +can be used to distinguish between float, double and long double versions. > > @end deftypefn > > > > This doesn't mention we'll ICE for anything but sincos. A sensible > > semantics would be that if TYPE is NULL the caller asks for support > > for all standard (float, double, long double) types while with TYPE > > non-NULL it can ask for a specific type including for example the > > new _FloatN, etc. types. > > > > Ack, updated accordingly and retested. > > OK for trunk? OK. Thanks, Richard. > Thanks, > - Tom