From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id CDF583858D28 for ; Fri, 31 Mar 2023 13:34:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CDF583858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x631.google.com with SMTP id kq3so21201374plb.13 for ; Fri, 31 Mar 2023 06:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680269642; x=1682861642; 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=sFkEoMvdPsbpkrHZWVSQDcCnSj+lF9E1HI4LBUSzHlQ=; b=iLTYqTPNBR2ukWgAQuDaQfJW5aSbkAMsvA1sypDImnSO/yqow4X7Woro+Sn8xxAru6 TJlIEgeO3dT9T75uzr/h0EZLqD4txgPriE4s/88jr0MZ2Ids8ocJjASJBdo2yTj/TWaE yjxOwBeumdW634tCwuU9PkrxBN5BSsHtJ/UUsD+S1sWqVJum0EqQju1mXl69m3DiWIfp WZIZsKyiIlqSov2FD8yeubSrPJGQXU3n+EPBA/b9gQ3nt2+z0H/SNVW0CR1f9VSJ3fSr DKGJW3NgG/cobsJB1ZTbPSuQvK4Vzx9MyMqOcjgLgHDZvGIiJH2sRloZxrke5UTOoxsf +Bjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680269642; x=1682861642; 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=sFkEoMvdPsbpkrHZWVSQDcCnSj+lF9E1HI4LBUSzHlQ=; b=Z08fVdNHO4HHgloBakZ4S2JmZh14LJNX3Di5nJU20b/mbhI3gcQlXeYouyRTJNPqh4 +rGw7oaptQv/N7rqhcgKUHMMKLMQnVBBAeqqf4HSIXMxpzTEifNG61itjlq3k3VDYhVk 18Lm8M2HGGdU1iQ6V2zyaMiOmQI/+db00CPcKD8YFQLGKAoPmN9iIVyVl85fDJSQ9cK5 oMuOHPXBLDVC1l5tOHtJ0GJ0JJR7gNFXcrvpX66n/ec/RS+OtJocRZvjozyXrTq1IdEq Dv9ri9F9aEEkCgP5xZ1EOUPKjiddpu5lfAIjD+lctAF1spAq6ixu0ejptv/cb6AraeXn EDcg== X-Gm-Message-State: AO0yUKXLBMPcE22dYW/Yn9Urn9YdmLpxPvf4XiJ+MNg6I3sCygms3AF5 DIetTQE8fTSkYhPtspLZEXo= X-Google-Smtp-Source: AK7set+iiEQ9aW7nboLue3wsD6zPFsydezOmYLgOKz1ArjO2/f4yyT6g/Tsbp9DLv2zlhJtOPLsf+A== X-Received: by 2002:a05:6a20:19a:b0:cb:f5ab:3bd0 with SMTP id 26-20020a056a20019a00b000cbf5ab3bd0mr21382648pzy.59.1680269641667; Fri, 31 Mar 2023 06:34:01 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id j26-20020aa783da000000b0062a7462d398sm1854250pfn.170.2023.03.31.06.34.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 31 Mar 2023 06:34:01 -0700 (PDT) Message-ID: <8ab51292-482b-9337-1569-889057178977@gmail.com> Date: Fri, 31 Mar 2023 07:34:00 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: ideas on PR/109279 Content-Language: en-US To: Vineet Gupta , Kito Cheng , Palmer Dabbelt Cc: gcc@gcc.gnu.org References: From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_NUMSUBJECT,NICE_REPLY_A,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: 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