From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) by sourceware.org (Postfix) with ESMTPS id 912933858C5F for ; Thu, 11 May 2023 17:51:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 912933858C5F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dabbelt.com Received: by mail-pf1-x430.google.com with SMTP id d2e1a72fcca58-643990c5373so9009922b3a.1 for ; Thu, 11 May 2023 10:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20221208.gappssmtp.com; s=20221208; t=1683827512; x=1686419512; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=qvC6ti4QgEkOcQhkSMxpdhZ+sIWaOj6f4gc6Bg6qC2s=; b=Uv1tI60nBcv0mENZXzJoBocCVwQYnn/TY5ChNjulX3jyYoUY/JGluRDNoDxRvwFXCo e3TgHNsaEsJ7vyqjJywlsCGbsp/m9LO0tiImI8i2NIXz04nzZAdMWV6cHgXp8L0I9pPn Yj7gkhswE5X3x1XkObtW2DLKDlcLSYmtXluVdZEWLnxnkexJU5WYcoxAAml/ZPIz3bV7 +MfwQ6PBH94OkdrPdQtT0Rd0Zb3Lx02kuDSYvq7vo20d6tIOuGHdGwuTA9wGHPXZt/iT RrhMsanYTi+x4NYkeIZcjzy7y03JmE6HlUsspNtrH1DTxe+z1mf7QKw+2xShHPppMdhX UbnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683827512; x=1686419512; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=qvC6ti4QgEkOcQhkSMxpdhZ+sIWaOj6f4gc6Bg6qC2s=; b=C9IJYoGohiyCkOSYyKetxrN6rvpn/89yVf8gUCIe/uyee6qcTX61vYt1Ybl5DwN43H l0ZKLYh8iiIklNwudcGC0+nAktLkyJvhxc2XpmMTQOdF0o0qg1iDrMSRGmzkMFm7a7Tp QJMN4OfGdrzM2AvIFgyfoSpI7RTE9nwKAViJQy/d7yKzhbfxWDyTcjaNAnVT78yDEeUe nZerEKXa5lc5ImzeTOfp82pziGEKje2J75uYJRAZd6qgHNh+5LK7uI4MkCp4771t3N1V f3wUKRylwWWbpMa151n0VFPPtSc2mW3jHzD9uNumDldjvrGCahsbyHX1w8SvYehLtwKe udYg== X-Gm-Message-State: AC+VfDwqHKvGvk82y1yFSRPAeCq3hpQh5QCBF1yUps5l844KE0cIFK2x V3aDYC9MkZGh+oPFpNPsl1YwrQ== X-Google-Smtp-Source: ACHHUZ6hBvVMG7OwCjej+kXOXI/jZI2qw1lXMx9qTnYzhzTEFp6HilTbaxV+Eb81JWfbli+qy81rLg== X-Received: by 2002:a05:6a00:2346:b0:63f:2f00:c6d with SMTP id j6-20020a056a00234600b0063f2f000c6dmr29119432pfj.2.1683827512445; Thu, 11 May 2023 10:51:52 -0700 (PDT) Received: from localhost ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id m22-20020aa78a16000000b0063b8f17768dsm5583493pfa.129.2023.05.11.10.51.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 May 2023 10:51:51 -0700 (PDT) Date: Thu, 11 May 2023 10:51:51 -0700 (PDT) X-Google-Original-Date: Thu, 11 May 2023 10:51:31 PDT (-0700) Subject: Re: [PATCH v2] RISC-V: Split off shift patterns for autovectorization. In-Reply-To: CC: rdapp.gcc@gmail.com, gcc-patches@gcc.gnu.org, juzhe.zhong@rivai.ai, Kito Cheng , collison@rivosinc.com From: Palmer Dabbelt To: jeffreyalaw@gmail.com Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 Thu, 11 May 2023 07:21:30 PDT (-0700), jeffreyalaw@gmail.com wrote: > On 5/11/23 04:33, Robin Dapp wrote: >>> "csr_operand" does seem wrong, though, as that just accepts constants. >>> Maybe "arith_operand" is the way to go? I haven't looked at the >>> V immediates though. >> >> I was pondering changing the shift-count operand to QImode everywhere >> but that indeed does not help code generation across the board. It can >> still work but might require extra patterns here and there. > Yea. It's a GCC wart and there hasn't ever been a clear best direction > on the mode for the shift count. If you use QImode, as you note you > often end up having to add various patterns to avoid useless conversions > and such. Yes, and I think given that we have so much weirdness for the sub-XLEN types in the RISC-V port we'd need to have a lot of fairly large patterns and some truncation-based fallbacks. We've got some of those for the integer shifts already, though, so maybe it's the way to go? FWIW, I was trying to suggest X or REG as the shift amount and thought we'd done it that way for the integer shifts too. I think we can reason about that with just some tiny code snippits, even if it's not the right way to go long term (as per below). Probably a minor win, though, and I don't think it needs to block the patches. Also: looks like I was wrong and "csr_operand" does the correct thing here because there's only a 5-bit immediate for the shift amounts. We should probably name it something else, though, as this has nothing to do with CSRs... > I suspect QImode isn't ideal on a target like RV where we don't really > have QImode operations. So all we do is force the introduction of > subregs all over the place to force the operand in to QImode. It's > something I'd like to explore, but would obviously require a fair amount > of benchmarking to be able to confidently say which is better. Folks have tried a few times and it's never ended up better. I do think we're at a local minimum here, though -- ie, explicitly handling the shorter types would result in better generated code if we got everything right. Gut feeling is that'd require a meaningful amount of middle-end work, though, as we're sufficiently different than MIPS here (and arm64/x86 have many of the ops). Nobody in Rivos land is looking at this right now, though it's a pretty common red flag for new people and frequently trips up code gen so that might change with little notice... > Jeff