From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) by sourceware.org (Postfix) with ESMTPS id 7BE193858C31 for ; Wed, 25 Oct 2023 23:28:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7BE193858C31 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7BE193858C31 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::236 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698276527; cv=none; b=UBRPCs5YstI7fZHcpfWpQfJeBIuBR3bxGmc80MEH2ERUDymA+H+KEkYgtXtV1XslKjEiPH7gcTslTl+2RSG2LVsj7lRGI5AVIMLlxrZwu1RLFOWdJRK5JotQ0PaHl1vnbntGODAjwsh65EnIjCenyP38gHBa0HLCdzoaVereB1E= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698276527; c=relaxed/simple; bh=A7zYHUWT59YIX6cxCyI/YseiKjO9wsDgZzizMrrk//Q=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=KQ9SCjCIwJaJSijBcd9KSaJuByXaPNeiWyhUuz0aPnEJm9LX9T1wDV4JfIwbTkGoFZUJek2jzcqWBb1sazAuQlTeVeMsOzDd0ofSTr1WPUgwP7lJHhUN500374gNf4KdyXBrQQ2kn/mv8srTb7a9B0wZKO7u7JN/jrPKzbwWH+I= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-oi1-x236.google.com with SMTP id 5614622812f47-3b2e308a751so148617b6e.0 for ; Wed, 25 Oct 2023 16:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1698276524; x=1698881324; darn=gcc.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=jLnWchLzq67c8RI+C3BGgPjS5jYRufpAIPT3Fdo32Dc=; b=Kzj+WNYkSKMGSDyFourNKi2IZGnm8haJuZvcT4bNcy5Zujf77d8ojjY/FWbWiN35Ol VTwMSb1TiNvJ3+YaOWPOExxk+swYoSjdPjwt5JujGpIhUk9HIRgM+B6jbB5JAIuFuTGS jFI+XFEm5IxNo8hngPH1gOxGoS16ns6ljKxD01LMNKWwNk0HQ5aCv8BhylxLtPhhmskP 5RYtSyzBHhDaU/QCqo4ALMcV0HEGmlgplopgrgvKhHURmfEg1XDonVKHGTyDmj+ZYPL6 KoWp8hkPD3/9RKwblkniKObltWnhfYiJ+fK3U0TZapsO8HQ2cpbiOBe3FMJHr86JWBKE 40ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698276524; x=1698881324; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jLnWchLzq67c8RI+C3BGgPjS5jYRufpAIPT3Fdo32Dc=; b=NhUU0VDHJC+ri4qD5REq6GzjKwZuU7heiY+A4CTu909Cc/xNXL3HW4gvHKccM+hW5X zCEKMvs3IgcS5dEPosl/bldH4Yz0wBYrEsM9X4hNLjESky9m3NlPyqkNEyNinxkmUMmb ZKLm5hKGpWi1T0Fi2X2zVFwC2w60Jb7z/c9bpp48UpDu99TpUIXtPRq1OQmGejZXMATZ DI9BudycSa+yWmTEq8zp1muDwagx7P/tIhWDMLlQVla0W82XhgkPT7SXdKj2d2p11Ocj OMn3ZccEtVye+y2egoMMLroU+6A31+fNftRczEt7dvmIWftH4gFpMaQLi8W2B7D0MQQI WFaQ== X-Gm-Message-State: AOJu0Yw8NQbkmU3aXpvHCeWcPkUDQjFdwwGKx4bVBulD9GnVb4d4yfMh g7l1Eo9fd0kIzWZBTUktopaLJcCyyLb017JkDV/6Jg== X-Google-Smtp-Source: AGHT+IG+c4zkaMbfDPEpOMsJLV+ShE/V+buMlkDBoM45EKDFb01IRJhcNaxQCT3YB0sr3MFDNr+73A== X-Received: by 2002:a05:6808:1a27:b0:3b2:f500:6ee0 with SMTP id bk39-20020a0568081a2700b003b2f5006ee0mr623141oib.28.1698276524491; Wed, 25 Oct 2023 16:28:44 -0700 (PDT) Received: from [192.168.50.117] (c-98-210-197-24.hsd1.ca.comcast.net. [98.210.197.24]) by smtp.gmail.com with ESMTPSA id x13-20020a54400d000000b003a7a34a4ed8sm2566088oie.33.2023.10.25.16.28.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Oct 2023 16:28:44 -0700 (PDT) Message-ID: <187929da-4181-4ec1-9918-d48c56d376a6@rivosinc.com> Date: Wed, 25 Oct 2023 16:28:43 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] RISC-V: elide sign extend when expanding cmp_and_jump Content-Language: en-US To: gcc-patches@gcc.gnu.org Cc: gnu-toolchain@rivosinc.com, Jeff Law , Robin Dapp References: <20231025050155.627837-1-vineetg@rivosinc.com> From: Vineet Gupta In-Reply-To: <20231025050155.627837-1-vineetg@rivosinc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00,BODY_8BITS,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: On 10/24/23 22:01, Vineet Gupta wrote: > RV64 comapre and branch instructions only support 64-bit operands. > The backend unconditionally generates zero/sign extend at Expand time > for compare and branch operands even if they are already as such > e.g. function args which ABI guarantees to be sign-extended (at callsite). > > And subsequently REE fails to eliminate them as > "missing defintion(s)" > specially for function args since they show up as missing explicit > definition. > > So elide the sign extensions at Expand time for a subreg promoted var > with inner word sized value whcih doesn't need explicit sign extending > (fairly good represntative of an incoming function arg). > > There are patches floating to enhance REE and/or new passes to elimiate > extensions, but it is always better to not generate them if possible, > given Expand is so early, the elimiated extend would help improve outcomes > of later passes such as combine if they have fewer operations/combinations > to deal with. > > The test used was existing gcc.c-torture/execute/20020506-1.c -O2 zbb > It elimiates the SEXT.W and an additional branch > > before after > ------- ------ > test2: test2: > sext.b a0,a0 > blt a0,zero,.L15 > bne a1,zero,.L17 bne a1,zero,.L17 > > This is marked RFC as I only ran a spot check with a directed test and > want to use Patrick's pre-commit CI to do the A/B testing for me. > > gcc/ChangeLog: > * config/riscv/riscv.cc (riscv_extend_comparands): Don't > sign-extend operand if subreg promoted with inner word size. > > Signed-off-by: Vineet Gupta > --- > gcc/config/riscv/riscv.cc | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc > index f2dcb0db6fbd..a8d12717e43d 100644 > --- a/gcc/config/riscv/riscv.cc > +++ b/gcc/config/riscv/riscv.cc > @@ -3707,7 +3707,16 @@ riscv_extend_comparands (rtx_code code, rtx *op0, rtx *op1) > } > else > { > - *op0 = gen_rtx_SIGN_EXTEND (word_mode, *op0); > + /* A subreg promoted SI of DI could be peeled to expose DI, eliding > + an unnecessary sign extension. */ > + if (GET_CODE (*op0) == SUBREG > + && SUBREG_PROMOTED_VAR_P (*op0) > + && GET_MODE_SIZE (GET_MODE (XEXP (*op0, 0))).to_constant () > + == GET_MODE_SIZE (word_mode)) > + *op0 = XEXP (*op0, 0); > + else > + *op0 = gen_rtx_SIGN_EXTEND (word_mode, *op0); > + > if (*op1 != const0_rtx) > *op1 = gen_rtx_SIGN_EXTEND (word_mode, *op1); > } Just a quick update that testing revealed additional failures and unpacking which took me a while and in hindsight embarrassing. I was misunderstanding what ABI guarantees and what ISA actually does :-) The ABI guarantees sign extension this for 32-bit things in 64-bit reg (so in rv64, int), but *not* 8-bit things in a reg. i.e. not for char arguments. e.g. uint8_t abs8(uint8_t x) {    if (x & 0x80) // SEXT.b a4, a0       ... } main() {     if (abs8(128) != 127)     // LI a0, 128  => ADDI a0, x0, 128        __builtin_abort(); } So my patch was optimizing away the SEXT.B (despite claiming that subreg prom of SI....) which is wrong. Sure ADDI in main () sign-extends, but it does that for 12-bit imm 0x080, which comes out to 0x80, but sign-extending for char scope 0x80 would yield 0xFFFF....0x80. Hence the issue. I'll spin a v2 after more testing. This is slightly disappointing as it reduces the scope of optimization, but correctness in this trade is non-negotiable :-) -Vineet