From patchwork Wed Jan 26 20:22:32 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Maciej W. Rozycki" X-Patchwork-Id: 50465 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 00FCF3857816 for ; Wed, 26 Jan 2022 20:22:54 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) by sourceware.org (Postfix) with ESMTPS id 7E7E33857C50 for ; Wed, 26 Jan 2022 20:22:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7E7E33857C50 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embecosm.com Received: by mail-lj1-x22f.google.com with SMTP id z20so1211351ljo.6 for ; Wed, 26 Jan 2022 12:22:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:user-agent:mime-version; bh=//ExKVII8Bep/dVn9Ra+9HcBwVqFnKB0m2u/Tza9ork=; b=D4JFtez7ioMg7k9p6g2VsQjvMZ52PXM6HlPkLzCP/gY1MmOwalukQDlbR6HZ+J2y3Y RQyvrOTsikN42Ux4ZQwLu/WpYt6sXIItSSMbe8/uOvGsQiwix7S8cbjEoku9JbFIDpYO igarUmg1bYZfSVmz7ap/wAodyAlu868zLcLk3klrwiKuh/+mXrJOGrwDAcOdAEounR3+ ElDnu+re9rACdm3TFr57V8q2J8hcrY5jz/Mn7lYtMhevEttkZHcFEiOAi1wYKtK/plLj YIaR2jFAwpwan49lLpT0keQiUn/rQ+O/WDV1kgni2JITkO2eROGcERLWIKsKOvStMBQ4 XhDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:user-agent :mime-version; bh=//ExKVII8Bep/dVn9Ra+9HcBwVqFnKB0m2u/Tza9ork=; b=y65sM/bppukzvnkaRZJShy5lY0Npa+GE8MPQD9aKzYGZBZGFnomENp42aLDmZuu2uX WTuR70q2dy4JWfArgqRJvodtMAwLyu+YfvjfYfQgdsXE5QKzBbvKl7htZ9HWsVO5QZP2 qi0CCPlcBDIde2Ag9rsHysWOWNL1V5hnr674mmN6atXen+KBs4gbPV1iDzsL5plECVwU EvekX6voWjL/7+2bNGEhfM9Hd0cozxPdlu15e11zuNexlKaoAfaoAlJtNk3BTpxXPGEL EXjbzmSesHdBFJktm0o8+Z7TIg7GxfonA9C0CVwEqnT72MyH+Stx5olQDq1jafU+KElN K/cQ== X-Gm-Message-State: AOAM530jrRPnhJsLQemBk/M/y82PZrFH2szwm2E1ajWWqm7GFQMEMaj9 m0WwzMMpNXfg6EndtzfIQdgk61qbBHq9l+rN X-Google-Smtp-Source: ABdhPJyyH4C4tk+CHBlNHOyuLtRy8Uh2K4wmuLLRLLpBYpgJpe25Ir+CxotbUwXdf1YYfGy+9/Pm7A== X-Received: by 2002:a05:651c:2107:: with SMTP id a7mr585451ljq.80.1643228555132; Wed, 26 Jan 2022 12:22:35 -0800 (PST) Received: from [192.168.219.3] ([78.8.192.131]) by smtp.gmail.com with ESMTPSA id d4sm1021725lfa.276.2022.01.26.12.22.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Jan 2022 12:22:34 -0800 (PST) Date: Wed, 26 Jan 2022 20:22:32 +0000 (GMT) From: "Maciej W. Rozycki" To: gcc-patches@gcc.gnu.org Subject: [PATCH v2][GCC13] RISC-V: Provide `fmin'/`fmax' RTL patterns Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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: , Cc: Kito Cheng , Joseph Myers , Andrew Waterman Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" As at r2.2 of the RISC-V ISA specification[1] the FMIN and FMAX machine instructions fully match our requirement for the `fminM3' and `fmaxM3' standard RTL patterns: "For FMIN and FMAX, if at least one input is a signaling NaN, or if both inputs are quiet NaNs, the result is the canonical NaN. If one operand is a quiet NaN and the other is not a NaN, the result is the non-NaN operand." suitably for the IEEE 754-2008 `minNum' and `maxNum' operations. However we only define `sminM3' and `smaxM3' standard RTL patterns to produce the FMIN and FMAX machine instructions, which in turn causes the `__builtin_fmin' and `__builtin_fmax' family of intrinsics to emit the corresponding libcalls rather than the relevant machine instructions. This is according to earlier revisions of the RISC-V ISA specification, which we however do not support anymore, as from commit 4b81528241ca ("RISC-V: Support version controling for ISA standard extensions"). As from r20190608 of the RISC-V ISA specification the definition of the FMIN and FMAX machine instructions has been updated[2]: "Defined the signed-zero behavior of FMIN.fmt and FMAX.fmt, and changed their behavior on signaling-NaN inputs to conform to the minimumNumber and maximumNumber operations in the proposed IEEE 754-201x specification." and specifically[3]: "Floating-point minimum-number and maximum-number instructions FMIN.S and FMAX.S write, respectively, the smaller or larger of rs1 and rs2 to rd. For the purposes of these instructions only, the value -0.0 is considered to be less than the value +0.0. If both inputs are NaNs, the result is the canonical NaN. If only one operand is a NaN, the result is the non-NaN operand. Signaling NaN inputs set the invalid operation exception flag, even when the result is not NaN." Consequently for forwards compatibility with r20190608+ hardware we cannot use the FMIN and FMAX machine instructions unconditionally even where the ISA level of r2.2 has been specified with the `-misa-spec=2.2' option where operation would be different between ISA revisions, that is the handling of signaling NaN inputs. Therefore provide new `fmin3' and `fmax3' patterns removing the need to emit libcalls with the `__builtin_fmin' and `__builtin_fmax' family of intrinsics, however limit them to where `-fno-signaling-nans' is in effect, deferring to the existing `smin3' and `smax3' patterns otherwise. For clarity and maintenance error resistance add an explicit condition to the latter patterns rather than relying on source code ordering for where the respective RTL insns are matched by their operation rather than being explicitly referred to by their names. References: [1] "The RISC-V Instruction Set Manual, Volume I: User-Level ISA", Document Version 2.2, May 7, 2017, Section 8.3 "NaN Generation and Propagation", p. 48 [1] "The RISC-V Instruction Set Manual, Volume I: Unprivileged ISA", Document Version 20190608-Base-Ratified, June 8, 2019, "Preface", p. ii [2] same, Section 11.6 "Single-Precision Floating-Point Computational Instructions", p. 66 gcc/ * config/riscv/riscv.md (fmin3, fmax3): New insns. (smin3, smax3): Only enable if `HONOR_SNANS'. --- Hi, This updated version has passed full GCC regression testing (including the D frontend this time) with the `riscv64-linux-gnu' target using the HiFive Unmatched (U74 CPU) target board. Any further questions or comments? Otherwise OK once GCC 13 has opened? Maciej Changes from v1: - Adjust heading from "RISC-V: Replace `smin'/`smax' RTL patterns with `fmin'/`fmax'". - Do not remove `smin'/`smax' patterns; instead make them available if `HONOR_SNANS (mode)'. - Make `fmin'/`fmax' patterns available if `!HONOR_SNANS (mode)' only. - Update description accordingly; refer r2.2 and r20190608 ISA specs. --- gcc/config/riscv/riscv.md | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) gcc-riscv-fmin-fmax.diff Index: gcc/gcc/config/riscv/riscv.md =================================================================== --- gcc.orig/gcc/config/riscv/riscv.md +++ gcc/gcc/config/riscv/riscv.md @@ -1214,11 +1214,29 @@ ;; ;; .................... +(define_insn "fmin3" + [(set (match_operand:ANYF 0 "register_operand" "=f") + (smin:ANYF (match_operand:ANYF 1 "register_operand" " f") + (match_operand:ANYF 2 "register_operand" " f")))] + "TARGET_HARD_FLOAT && !HONOR_SNANS (mode)" + "fmin.\t%0,%1,%2" + [(set_attr "type" "fmove") + (set_attr "mode" "")]) + +(define_insn "fmax3" + [(set (match_operand:ANYF 0 "register_operand" "=f") + (smax:ANYF (match_operand:ANYF 1 "register_operand" " f") + (match_operand:ANYF 2 "register_operand" " f")))] + "TARGET_HARD_FLOAT && !HONOR_SNANS (mode)" + "fmax.\t%0,%1,%2" + [(set_attr "type" "fmove") + (set_attr "mode" "")]) + (define_insn "smin3" [(set (match_operand:ANYF 0 "register_operand" "=f") (smin:ANYF (match_operand:ANYF 1 "register_operand" " f") (match_operand:ANYF 2 "register_operand" " f")))] - "TARGET_HARD_FLOAT" + "TARGET_HARD_FLOAT && HONOR_SNANS (mode)" "fmin.\t%0,%1,%2" [(set_attr "type" "fmove") (set_attr "mode" "")]) @@ -1227,7 +1245,7 @@ [(set (match_operand:ANYF 0 "register_operand" "=f") (smax:ANYF (match_operand:ANYF 1 "register_operand" " f") (match_operand:ANYF 2 "register_operand" " f")))] - "TARGET_HARD_FLOAT" + "TARGET_HARD_FLOAT && HONOR_SNANS (mode)" "fmax.\t%0,%1,%2" [(set_attr "type" "fmove") (set_attr "mode" "")])