From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id 3BFF2385DC23 for ; Fri, 2 Jul 2021 07:37:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3BFF2385DC23 Received: by mail-ej1-x636.google.com with SMTP id gt10so13323531ejc.5 for ; Fri, 02 Jul 2021 00:37:06 -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=01VYJoPSShMQ6aHdgM4g06Yc3mP8K8xBC2a+IjWX6Wg=; b=ZuzxatU6smeWibuvZodRsyAQuGC9k6Y13bCWrg9lCLMILlbdpUQ/qKc+qBaUv7tMPO eRRWuMu1OcnKVZm2TI9X643LYQ0zqHx1nOcYuF899OnMk5zMkooZLXoQ0A3CE5vTY0Xd rl49dpHKHcQJaEyyK1k8mUnCqgbjXaD2Fm/BfP5EbdaMcE2CyVbJRlGzNJIZyFiTJ5az Sh0GU5LgopIFt68hFHknJ9j/TcYVEUsk05GfQkYqbF47gUYYIS2zC+GF4dOjJHv++c24 x/ZKdYBazvoD3WRz20MreyQkrEMtEhCmUydwZBST6WaLT2bhjFbMFI2daZRM7pfrcF9q IWzg== X-Gm-Message-State: AOAM530VCfJf5Z88lR6shQzjpphwadLpLDNNEpbHLb46tRGZZiISbn60 dCLJob1Pava3FEc2LbH3DzE4MtlyRcZsP77hRCA= X-Google-Smtp-Source: ABdhPJxF4KzQN0kI++J7Ufp5z3sfAPiXylzlhQcdoMM/GODpzXwHYpfHV+FBSek/0BMORPN75y2PVdwBECDoc58Dz1w= X-Received: by 2002:a17:906:3c44:: with SMTP id i4mr4074627ejg.371.1625211425253; Fri, 02 Jul 2021 00:37:05 -0700 (PDT) MIME-Version: 1.0 References: <20210701061648.9447-1-hongtao.liu@intel.com> <20210701061648.9447-59-hongtao.liu@intel.com> In-Reply-To: From: Richard Biener Date: Fri, 2 Jul 2021 09:36:54 +0200 Message-ID: Subject: Re: [PATCH 58/62] AVX512FP16: Optimize for code like (_Float16) __builtin_ceif ((float) f16). To: Joseph Myers Cc: liuhongt , Jakub Jelinek , GCC Patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.4 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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Fri, 02 Jul 2021 07:37:07 -0000 On Thu, Jul 1, 2021 at 11:26 PM Joseph Myers wrote: > > On Thu, 1 Jul 2021, liuhongt via Gcc-patches wrote: > > > +/* Optimize for code like (_Float16) __builtin_ceif ((float) f16) > > + since it's not handled in frontend. */ > > Much the same comments apply as for sqrt. But in this case, the > conversion code is in match.pd - right now, specific to pairs of types > (float, double) and (float, long double). And it's logically valid for > any pair of same-radix floating-point types, the values of one of which > are a subset of the values of the other (a strict subset, for it actually > to be an interesting optimization). (So when making it apply to more > general types, take care that it does *not* apply to the __ibm128 / > _Float128 pair on powerpc64le, in either order, because neither of those > types has values a subset of the other.) > > (Also, the match.pd code isn't handling roundeven at present, but that > should be a trivial addition to it.) Note that for non-"standard" float formats emitting builtins would require guaranteed libm support (IIRC we don't have rounding functions in libgcc), so guarding on availability of a machine instruction (optab) for the operation should be tested instead - see my proposed match rule for sqrt and using internal-functions and the direct optab machinery. Richard. > -- > Joseph S. Myers > joseph@codesourcery.com