From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) by sourceware.org (Postfix) with ESMTPS id E59BB3858D28 for ; Fri, 31 Mar 2023 14:14:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E59BB3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-lj1-x22d.google.com with SMTP id h9so23176534ljq.2 for ; Fri, 31 Mar 2023 07:14:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1680272050; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=UyMPNeKf3n7NbzIF8zAi4cYhQnkBKVgQjw89/1825SY=; b=VHpUU6SmG+Ylp9eK6j2gP1LtDO5ZO9mxQzE4dd66RRMdag3y3UMMzGPBDrLZQVjTwx lb+R1fRWW9hvXE29UixN7Loi6GAoK0arllYiZ6d+1+q5hRCbKDjuuIiyS6MmoFFpANzq 3/50twJcOD5IcBuKW1tMlb3v7BNp1q10FfG2YSgRNQicjRl0lhLUml4yrvWK2dmyO3hO s4g1torczYdD7ngQiwQfzPv35tlMjABZYkeOQgl6ve1ebOLww8A9y+vR9yR1tQubxtsb OugfO2Q8DNLgggoPgn5cr2sJ1+XzcYzXEZPKLnBxyFXhCg2lQ98wjEqtIDlYazR+H78W ORuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680272050; 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=UyMPNeKf3n7NbzIF8zAi4cYhQnkBKVgQjw89/1825SY=; b=DsuVW6NQxwyZspcEd3xQPsqH7CZManIEcT9pTvX0OdO4besnvDeDU97ednQV//a0np WuOfRfYGcFeaPP8p0Vvgvy2DMQE8L/6Qk3NkvhZYZHn+oCKN+WmAl+dd1FlJeprpNndN uR1TiQdPEip1NFe9/6FrhCC+lMieHeqP5Pj7wvXQRTPgV4i+sgl25IW54odLlKVyGD1f rTPq6hknd1Hd7AB2OU+fJoWlexNMjx7wSXIriWeIUxrxZvop+luUCEtMxfa9aJ9CdF66 oTre2FLotRmLYgbWKQrVzMcEqWcgaF5qxFxaE1HI9wSrgPM61DwWvsFIHMTrPoElrggn 1I2w== X-Gm-Message-State: AAQBX9d7AwfiCYFqsQO/J3zEyt1RjuWkMShmcbA1ww1Z6+2lRlp83CKR gHKDE2I6RY6J4ZGPdwZ34oN4RnpxEI/lAkeA98PDxA== X-Google-Smtp-Source: AKy350Zb1irE7+tkBDeDYFC4GtBBokCAC6bzpK3OaZNvXIyzbe2aSMO/ogJnVj00pv4Rc7d8NnlD0exKSwiKjtDbqy4= X-Received: by 2002:a2e:998a:0:b0:29b:ebfa:765a with SMTP id w10-20020a2e998a000000b0029bebfa765amr8283401lji.6.1680272050323; Fri, 31 Mar 2023 07:14:10 -0700 (PDT) MIME-Version: 1.0 References: <8ab51292-482b-9337-1569-889057178977@gmail.com> In-Reply-To: <8ab51292-482b-9337-1569-889057178977@gmail.com> From: Kito Cheng Date: Fri, 31 Mar 2023 22:13:59 +0800 Message-ID: Subject: Re: ideas on PR/109279 To: Jeff Law Cc: Palmer Dabbelt , Vineet Gupta , gcc@gcc.gnu.org Content-Type: multipart/alternative; boundary="000000000000afa5f905f832d22f" X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000afa5f905f832d22f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would prefer defer to GCC 14 too Jeff Law =E6=96=BC 2023=E5=B9=B43=E6=9C=8831=E6=97= =A5 =E9=80=B1=E4=BA=94=EF=BC=8C21:34=E5=AF=AB=E9=81=93=EF=BC=9A > > > On 3/31/23 03:11, Vineet Gupta wrote: > > Hi Jeff, Kito, > > > > I need some ideas to proceed with PR/109279: pertaining to longer term > > direction and short term fix. > > > > First the executive summary: > > > > long long f(void) > > { > > return 0x0101010101010101ull; > > } > > > > Up until gcc 12 this used to generate const pool type access. > > > > lui a5,%hi(.LANCHOR0) > > ld a0,%lo(.LANCHOR0)(a5) > > ret > > .LC0: > > .dword 0x101010101010101 > > > > After commit 2e886eef7f2b ("RISC-V: Produce better code with complex > > constants [PR95632] [PR106602] ") it gets synthesized to following > > > > li a0,0x01010000 > > addi a0,0x0101 > > slli a0,a0,16 > > addi a0,a0,0x0101 > > slli a0,a0,16 > > addi a0,a0,0x0101 > > ret > > > > Granted const pool could or not be preferred by specific uarch, will > > the long term approach be to have a cost model for the const pool vs. > > synthesizing. > > > > The second aspect is to improve the horror above. Per chat on IRC, > > pinskia suggested we relax the in_splitter constraint in > > riscv_move_integer, as the combine issue holding it back is now fixed - > > after commit 61bee6aed26eb30. > > > > That beings it down to some what reasonable > > > > li a5,0x01010000 > > addi a5,a5,0x0101 > > mv a0,a5 > > slli a5,a5,32 > > add a0,a5,a0 > > ret > > > > I can spin a minimal patch, will that be acceptable for gcc 13.1 if it > > is testsuite clean > It would seem to be a gcc-14 thing to me. > > It seems like we probably should adjust the basic constant synthesis > code to handle this class of cases so that the initial RTL is good > rather than waiting on combine to fix it up. It looks like we need the > destination register as well as a temporary and a 5 instruction sequence. > > I'm aware of uarch plans that would handle this kind of sequence > entirely in the front-end and pass off a single uop to the execution > units. We'd planned to dig into constant synthesis in support of that > effort. So I'm happy to help shepherd this improvement once gcc-14 > development opens. > > jeff > --000000000000afa5f905f832d22f--