From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id 4D1C83858D1E for ; Fri, 1 Sep 2023 19:53:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4D1C83858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-pl1-x630.google.com with SMTP id d9443c01a7336-1bf078d5f33so19606955ad.3 for ; Fri, 01 Sep 2023 12:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1693597994; x=1694202794; darn=gcc.gnu.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=NOyj8diTypVqWL8R426SlJ/QiZy5NfC/KNWIaedp3c4=; b=FED81VLQ/uVEnYXCobn11mLz4VQ1eJsJIuzSL5iLVgAwjiOv+kp1SaTH4oZTuMIrg/ 84WnZ0wfXol0f2KD52YxBxYZbzP+0bIctp4Rbv05K5b/Yr1ORjnJ4hXk47GFECkv/JZc 122AG9/4mIaRNqJ+K4G9QrNTe7SUG2K8WHoowcLgjxqg5nLahoB+HnvH7KTeNucmPWqG Ppk4Z2HeNaktnO4L00ZYmP0BjiEXlEe/TMXhYEZqXaLzjU5TeeUY628hF0ZTZWbAmvcc /IVtwfQ5Wc4I3HEzRx/9wkIbz2wU1e0FTB0/iu8RyV3xyyEaSgNWthPMVGARM3i9XkHq QxOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693597994; x=1694202794; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=NOyj8diTypVqWL8R426SlJ/QiZy5NfC/KNWIaedp3c4=; b=UlT0+8IcR+yw7W77ktFucd1VLFSGAjEruQJnXpu1P73P2DSc4NkpO53vOgbuo7QRlr 7DwxpFecE6GOQZvsaL/zViAclinUmN8td/v6yuAMjOrK+mQOqypfRvVbigWYjVVWxpdt HojNl2z5Wh5r3XcQ9E8/yotCi+s3Qt3lCcS9lnfI7E5V6FtIeBof/pkVuGVoiLVFZIup ppvOtlE/vSb+Gb7i8R2P+0uu7/vs3RR48W+BuZCVWzl8uTJZrOndrHxo5/z2RYZblKMP /q2hbVmLksniKiFWfuOa2LrxZ5xGJ2ukobZ603Y3xBaeXjS1//ko3KqQ7g3xEoxHizxy MaJw== X-Gm-Message-State: AOJu0YxHMnXftsma8WMLifnA5C0XRTckZ9enLNtYFiuJ0Ful/e3h2bHf 3i9TgMcYvZPYyg6vkEhluz/KzBxGv9c5/wdGmQM= X-Google-Smtp-Source: AGHT+IG7y76K7ZAKN7JdysFc30r2km2ihLzdehNxeFlI4xdY0HXrvLIpuYARemEesSUnGoOKJQZnzA== X-Received: by 2002:a17:903:22ce:b0:1bb:a4e4:54b6 with SMTP id y14-20020a17090322ce00b001bba4e454b6mr4202057plg.62.1693597993703; Fri, 01 Sep 2023 12:53:13 -0700 (PDT) Received: from vineet-framework.ba.rivosinc.com (c-98-210-197-24.hsd1.ca.comcast.net. [98.210.197.24]) by smtp.gmail.com with ESMTPSA id ix21-20020a170902f81500b001bba7aab826sm3359155plb.163.2023.09.01.12.53.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Sep 2023 12:53:13 -0700 (PDT) From: Vineet Gupta To: gcc-patches@gcc.gnu.org Cc: kito.cheng@gmail.com, Jeff Law , Palmer Dabbelt , gnu-toolchain@rivosinc.com, Vineet Gupta Subject: [PATCH v2] RISC-V: zicond: Fix opt2 pattern Date: Fri, 1 Sep 2023 12:53:11 -0700 Message-Id: <20230901195311.761131-1-vineetg@rivosinc.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-11.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This was tripping up gcc.c-torture/execute/pr60003.c at -O1 since in failing case, pattern's asm czero.nez gets both rs2 and rs1 as non zero. We start with the following src code snippet: if (a == 0) return 0; else return x; } which is equivalent to: "x = (a != 0) ? x : a" where x is NOT 0. ^^^^^^^^^^^^^^^^ and matches define_insn "*czero.nez..opt2" | (insn 41 20 38 3 (set (reg/v:DI 136 [ x ]) | (if_then_else:DI (ne (reg/v:DI 134 [ a ]) | (const_int 0 [0])) | (reg/v:DI 136 [ x ]) | (reg/v:DI 134 [ a ]))) {*czero.nez.didi.opt2} The corresponding asm pattern generates czero.nez x, x, a ; %0, %2, %1 which implies "x = (a != 0) ? 0 : a" clearly not what the pattern wants to do. Essentially "(a != 0) ? x : a" cannot be expressed with CZERO.nez if X is not guaranteed to be 0. However this can be fixed with a small tweak "x = (a != 0) ? x : a" is same as "x = (a == 0) ? a : x" since middle operand is 0 when a == 0. which can be expressed with CZERO.eqz before fix after fix ----------------- ----------------- li a5,1 li a5,1 ld a4,8(sp) ld a4,8(sp) # a4 is runtime non zero czero.nez a0,a4,a5 # a0=0 NOK czero.eqz a0,a4,a5 # a0=a4!=0 OK The issue only happens at -O1 as at higher optimization levels, the whole conditional move gets optimized away. This fixes 4 testsuite failues in a zicond build: FAIL: gcc.c-torture/execute/pr60003.c -O1 execution test FAIL: gcc.dg/setjmp-3.c execution test FAIL: gcc.dg/torture/stackalign/setjmp-3.c -O1 execution test FAIL: gcc.dg/torture/stackalign/setjmp-3.c -O1 -fpic execution test gcc/ChangeLog: * config/riscv/zicond.md: Fix op2 pattern. Fixes: 1d5bc3285e8a ("[committed][RISC-V] Fix 20010221-1.c with zicond") Signed-off-by: Vineet Gupta --- changes since v1 - instead of discarding opt2 pattern, fix the asm --- gcc/config/riscv/zicond.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/config/riscv/zicond.md b/gcc/config/riscv/zicond.md index 4619220ef8ac..1721e1011ea8 100644 --- a/gcc/config/riscv/zicond.md +++ b/gcc/config/riscv/zicond.md @@ -60,7 +60,7 @@ (match_operand:GPR 2 "register_operand" "r") (match_operand:GPR 3 "register_operand" "1")))] "TARGET_ZICOND && rtx_equal_p (operands[1], operands[3])" - "czero.nez\t%0,%2,%1" + "czero.eqz\t%0,%2,%1" ) ;; Combine creates this form in some cases (particularly the coremark -- 2.34.1