From patchwork Thu Sep 28 21:43:41 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vineet Gupta X-Patchwork-Id: 1841009 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.a=rsa-sha256 header.s=20230601 header.b=WtIzPNZH; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=server2.sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=patchwork.ozlabs.org) Received: from server2.sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4RxRnl35r5z1yp0 for ; Fri, 29 Sep 2023 07:44:03 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BE8803856DC0 for ; Thu, 28 Sep 2023 21:43:59 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) by sourceware.org (Postfix) with ESMTPS id CE8073858C52 for ; Thu, 28 Sep 2023 21:43:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CE8073858C52 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-pf1-x435.google.com with SMTP id d2e1a72fcca58-690ba63891dso10562797b3a.2 for ; Thu, 28 Sep 2023 14:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1695937424; x=1696542224; 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=/JifjHpGl/lvrVK1+edfqHe859axCCAkQGzYBwlIkeI=; b=WtIzPNZHkMsZGwK3YV1PpsNVy0+EJeSdZLTi6FjL8+PKlkvfZDt36mE39rNBf37rwl lysIJJkgeiSZiJ1C+57nOE+u1gESKjOWq4DfKWoiXOtb6oYmqtqJ4fRCLCNi8yoXdYEK hWumTAkFcMH5UXtdbLW6ncGCC+W9OV9z/LbX1tFcnBlPT6GbvZ0UU+MfsmW63u3MDabV VBWJJR/nBqa59zwPQpu2Cb4G1UzD2B8zbMSvyBns5DTl5jW4yGPa13A583jLr87go4Bk Wel8wPap5+HU/w43lrhpLDc9oYVvGkmDMzzUmOAKoEWuehJh0uJXv/Ssd02u+GNnNPOD rABg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695937424; x=1696542224; 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=/JifjHpGl/lvrVK1+edfqHe859axCCAkQGzYBwlIkeI=; b=a8pydFuOaeGOxRvPSRD1uqv9i6wIUOJ+fXLmE2PVQjq+/MQVS0Rj/wE84vv1P93wM6 D9Wzmdv/BOplgde2j3sLwlO+NRMgRv4f+OrMXU2xvS2tJRg2rPpgoG2YQhxLYXoV5LYU rlyQzQMLLTLtj6r9LlShQUgMaDpVoiZyWDft+9UJrDzmyZ2XQkYmMpKbK2seSbf5w+Rd 40eN0GRWlcjKITNdldRCtnjKiF6MbXK1kgaC2mE4mv4s8tNakiSFSHHZ+yjm87SP9O2X dd7zLCHlraUSp5Dm6xWKCumOWr36KJTyWHF6YFrjU1saiIcr0bxc6dx3QD+D9FzZjU01 //MA== X-Gm-Message-State: AOJu0YzW3OwCgmK+hbfkILCv4IFsbMhiSqTShdXJWdAvVyAwt2ETihTe ykejoRJJtFE/1lCUJJwgCAh0XDtf2q6b6VmYNvo= X-Google-Smtp-Source: AGHT+IE8+g2UNTQBsoUbiupsZx0pPDrbdLuSdr3WJmT0Ej/7GZEd327hCbyKXHjqA3ctrSMd/Zid8g== X-Received: by 2002:a05:6a21:3e04:b0:161:25e4:e64a with SMTP id bk4-20020a056a213e0400b0016125e4e64amr2454862pzc.57.1695937424601; Thu, 28 Sep 2023 14:43:44 -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 a8-20020a637f08000000b0057d86bb613esm11069277pgd.45.2023.09.28.14.43.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Sep 2023 14:43:44 -0700 (PDT) From: Vineet Gupta To: gcc-patches@gcc.gnu.org, Robin Dapp Cc: kito.cheng@gmail.com, Jeff Law , Palmer Dabbelt , gnu-toolchain@rivosinc.com, Roger Sayle , Jakub Jelinek , Jivan Hakobyan , Vineet Gupta Subject: [RFC] expr: don't clear SUBREG_PROMOTED_VAR_P flag for a promoted subreg [target/111466] Date: Thu, 28 Sep 2023 14:43:41 -0700 Message-Id: <20230928214341.257862-1-vineetg@rivosinc.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 X-Spam-Status: No, score=-10.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, KAM_SHORT, 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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org RISC-V suffers from extraneous sign extensions, despite/given the ABI guarantee that 32-bit quantities are sign-extended into 64-bit registers, meaning incoming SI function args need not be explicitly sign extended (so do SI return values as most ALU insns implicitly sign-extend too.) Existing REE doesn't seem to handle this well and there are various ideas floating around to smarten REE about it. RISC-V also seems to correctly implement middle-end hook PROMOTE_MODE etc. Another approach would be to prevent EXPAND from generating the sign_extend in the first place which this patch tries to do. The hunk being removed was introduced way back in 1994 as 5069803972 ("expand_expr, case CONVERT_EXPR .. clear the promotion flag") This survived full testsuite run for RISC-V rv64gc with surprisingly no fallouts: test results before/after are exactly same. | | # of unexpected case / # of unique unexpected case | | gcc | g++ | gfortran | | rv64imafdc_zba_zbb_zbs_zicond/| 264 / 87 | 5 / 2 | 72 / 12 | | lp64d/medlow Granted for something so old to have survived, there must be a valid reason. Unfortunately the original change didn't have additional commentary or a test case. That is not to say it can't/won't possibly break things on other arches/ABIs, hence the RFC for someone to scream that this is just bonkers, don't do this :-) I've explicitly CC'ed Jakub and Roger who have last touched subreg promoted notes in expr.cc for insight and/or screaming ;-) Thanks to Robin for narrowing this down in an amazing debugging session @ GNU Cauldron. ``` foo2: sext.w a6,a1 <-- this goes away beq a1,zero,.L4 li a5,0 li a0,0 .L3: addw a4,a2,a5 addw a5,a3,a5 addw a0,a4,a0 bltu a5,a6,.L3 ret .L4: li a0,0 ret ``` Signed-off-by: Vineet Gupta Co-developed-by: Robin Dapp --- gcc/expr.cc | 7 ------- gcc/testsuite/gcc.target/riscv/pr111466.c | 15 +++++++++++++++ 2 files changed, 15 insertions(+), 7 deletions(-) create mode 100644 gcc/testsuite/gcc.target/riscv/pr111466.c diff --git a/gcc/expr.cc b/gcc/expr.cc index 308ddc09e631..d259c6e53385 100644 --- a/gcc/expr.cc +++ b/gcc/expr.cc @@ -9332,13 +9332,6 @@ expand_expr_real_2 (sepops ops, rtx target, machine_mode tmode, op0 = expand_expr (treeop0, target, VOIDmode, modifier); - /* If the signedness of the conversion differs and OP0 is - a promoted SUBREG, clear that indication since we now - have to do the proper extension. */ - if (TYPE_UNSIGNED (TREE_TYPE (treeop0)) != unsignedp - && GET_CODE (op0) == SUBREG) - SUBREG_PROMOTED_VAR_P (op0) = 0; - return REDUCE_BIT_FIELD (op0); } diff --git a/gcc/testsuite/gcc.target/riscv/pr111466.c b/gcc/testsuite/gcc.target/riscv/pr111466.c new file mode 100644 index 000000000000..007792466a51 --- /dev/null +++ b/gcc/testsuite/gcc.target/riscv/pr111466.c @@ -0,0 +1,15 @@ +/* Simplified varaint of gcc.target/riscv/zba-adduw.c. */ + +/* { dg-do compile } */ +/* { dg-options "-march=rv64gc_zba_zbs -mabi=lp64" } */ +/* { dg-skip-if "" { *-*-* } { "-O0" } } */ + +int foo2(int unused, int n, unsigned y, unsigned delta){ + int s = 0; + unsigned int x = 0; + for (;x