From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) by sourceware.org (Postfix) with ESMTPS id 037613810AC1 for ; Thu, 8 Dec 2022 06:25:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 037613810AC1 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-qt1-x830.google.com with SMTP id x28so380854qtv.13 for ; Wed, 07 Dec 2022 22:25:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=il46wG2v6TQDWP0xQrjFppA5n+2+S73k0SFbQAk2WaY=; b=L44Co+cbOEyKdsy8/4rqN8bC6Qv5BbHGZp92amPZo3x+L1FLlpCPS9r1JQByt55MTP vQpNp9d+CD9bRboJjrEJE36Yf37U1Mxp5ba1piWCPjp5L/xNaqSyWv6seNTihfLHIfn1 Xjux1T2qqVEdzYbM7hhIhVK1txiiZXjb6/pQxyFZcV4K/BIODBTltQR0WLEjXAlpzkoM GWYBI6aK5jCNrLoG6LfNAYg5XaSeKN0cQ0mEUnRQdF+1Dd5bUeyuB+F8Ddpx8lZY7POc 45W87FA4aBDs4JtGi1zuTctCMEC/YKfClsCImSlBetKKjzUNLzb96fLwvcZo/qXNAB+3 PA5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=il46wG2v6TQDWP0xQrjFppA5n+2+S73k0SFbQAk2WaY=; b=1sNY7fcTD31zcwPBF4adu9IOCkyzYORpGsAjHAlBzSsn5my4lrYbW23Fp7xBgvN8WS 997N5gu/xX/U2H0KWZq0jiv8DEnHfcDU3868WcfWKWExCUVnnhxj3IE+ebUJgTwANs0C 8J0+yUOD1YGiTxh/JeIqxNS4pSK9jVdFATkrQdCGCxz0bgtzgVLfbeY6BhMCncuzD2n1 JM+Ol28OoeNHQGIBKsEzRpLORJSSXl1SjzfM2TxfCQaYIVj7Wt6n3geY6vCoxrPfJiVw /6XmGvdjRydz6V/Dw0RQ7RCy/EbbpTcy0m3fd4Uf/55XyVt6LnXYq1rdO4jtpHwYyomH pOxw== X-Gm-Message-State: ANoB5pkSs4BKKGdPFw4tlXNi55FgSXSLwPhzOG5YNuP9ImP9IvT/jF3u zGcGaI+ee7CBAS/q3Ypi8Yadep/pA/zeepA2 X-Google-Smtp-Source: AA0mqf4XASx+OEiorgYsDRmmFPunrKURGvniE2wftKFmhwPxPnnBu71qqmPIP1ZrDjL67q9H1DqVlQ== X-Received: by 2002:ac8:4788:0:b0:3a7:f8fc:ba48 with SMTP id k8-20020ac84788000000b003a7f8fcba48mr759492qtq.34.1670480740182; Wed, 07 Dec 2022 22:25:40 -0800 (PST) Received: from mail-yw1-f171.google.com (mail-yw1-f171.google.com. [209.85.128.171]) by smtp.gmail.com with ESMTPSA id dc53-20020a05620a523500b006fefa5f7fcesm1709564qkb.10.2022.12.07.22.25.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Dec 2022 22:25:39 -0800 (PST) Received: by mail-yw1-f171.google.com with SMTP id 00721157ae682-3e78d07ab4fso4174887b3.9; Wed, 07 Dec 2022 22:25:38 -0800 (PST) X-Received: by 2002:a81:cc8:0:b0:36a:f032:5b4c with SMTP id 191-20020a810cc8000000b0036af0325b4cmr23658703ywm.114.1670480738621; Wed, 07 Dec 2022 22:25:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andrew Waterman Date: Wed, 7 Dec 2022 20:25:27 -1000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [Bug target/106585] RISC-V: Mis-optimized code gen for zbs To: "palmer at gcc dot gnu.org" Cc: gcc-bugs@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 List-Id: On Wed, Dec 7, 2022 at 7:02 PM palmer at gcc dot gnu.org via Gcc-bugs wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585 > > palmer at gcc dot gnu.org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |palmer at gcc dot gnu.org > > --- Comment #8 from palmer at gcc dot gnu.org --- > (In reply to Jeffrey A. Law from comment #7) > > Raphael and I are poking at this a bit. I can't convince myself that it's > > actually safe to use GPR for the bit manipulation patterns. > > > > For rv64 I'm pretty sure the b* instructions are operating on 64bit > > quantities only. Meaning they might twiddle the SI sign bit without > > extending. If we were to change these patterns to use GPR and the result > > then fed an addw (for example) then we would have inconsistent register > > state as operand twiddled by the prior b* pattern wouldn't have been sign > > extended. > > > > To be clear, I think this is a limitation imposed by the ISA docs, not GCC > > where this will be reasonably well defined. > > So you're worried about addw (and the various other OP-32 instructions) needing > signed extended high parts in registers in order to function as expected? I've > never gotten that from the ISA manual, there might be some vestigial MIPS-isms > floating around the RISC-V port that indicate that though (as we've got similar > constraints for the comparisons). > > That said, I'v gone and actually read the ISA manual here and it's not at all > specific. I'm seeing > > ADDW and SUBW are RV64I-only instructions that are defined analogously > to ADD and SUB but operate on 32-bit values and produce signed 32-bit > results. Overflows are ignored, and the low 32-bits of the result is > sign-extended to 64-bits and written to the destination register. > > which doesn't explicitly say the high 32-bits of the inputs are ignored. As > far as I can tell "32-bit values" isn't defined anywhere, so that's not so > useful. > > Do you know if there's any hardware that needs extended values for addw and > friends? That'd almost certainly break a lot of binaries, but I could > certainly buy an argument saying it's to the spec (and the actual words in the > spec, not just this "anything goes" compatibility stuff). The spec explicitly says that the upper 32 bits of the inputs are ignored; you just need to read a few paragraphs up. https://github.com/riscv/riscv-isa-manual/blob/b7080e0d18765730ff4f3d07b866b4884a8be401/src/rv64.tex#L18-L21 > > > With that in mind I think the only path forward is new patterns that (sadly) > > use explicit subregs for sources, but still set a DImode destination. > > > > I'm the newbie here, so if I've misinterpreted the ISA docs incorrectly, > > don't hesitate to let me know. > > Kind of just a related FYI: the comparison instructions and various bits of the > ABI do require values in canonical forms (the ABI stuff isn't exactly sign > extended, but there's a rule). That's all a big fragile.