From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) by sourceware.org (Postfix) with ESMTPS id 8CF243858D33 for ; Fri, 31 Mar 2023 09:11:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8CF243858D33 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-pl1-x62d.google.com with SMTP id o11so20702680ple.1 for ; Fri, 31 Mar 2023 02:11:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; t=1680253861; h=content-transfer-encoding:subject:cc:to:from:content-language :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=EoShF4lFHLYnAkCCgwsiL8gPD54al5qun1srzqSsFyY=; b=hDLXdLXUELK/6gVVmh7xgJIu55gAuzktju70bqNguS9ztuiXXYGaa9Kn6ZGkSqLs07 b3CrmTlxZcNO7d28r5S+kQdiKnsoIKgp22ISbvX0GlaLQDT6gL6GW7d9RDKViKYCydIF fZlePJTdGxAto9WK9xmo2JnJdceKk32j2b0G8PbMzxxNzensUbziAP7x1k7DCDc8GrlI MthXvWSeQbwL9iZK1J/xZP0k2LYPTaCQobwSJMRLO3UDLmrzEN1w3hA0JvpiHcYq9K+x TecQlUenpQYWxYSqwul5QQvlZ21+BHyVXNc2ODemF7Rd8HDO0MbJmG8D06G93pdMqb1w 6rbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680253861; h=content-transfer-encoding:subject:cc:to:from:content-language :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=EoShF4lFHLYnAkCCgwsiL8gPD54al5qun1srzqSsFyY=; b=I4CqJ+nvo8kgWKK61ZHfaVgvmn0PS3ddiLSUvAtDRxoxYIMDh3n9o33Tsqpg6EJY7b VYCLVXxhOR7/Ip3bTUiEz2BnWGD5liRFpyczCwO5J76zfVyWwp8OFQlMOXWe/zBJJees sBGLtb3ZJnhh01TQOSvpYUE60Az1zN29hfb3ipRZfflL/+gkymUXQBwxQFUV/Sl5hTSt q7AGpfHe9uTpB+k66T9BO7BItPq+9OPLlVPkzM79qU26KTH7XlntqExytnlGx5nT8Oje vzK02s+q+ULBA0ckPMup8x6Qfq50m8fHlHjmBDDuM1kgiH0oUGi6nVVO67DxxCgrGHhY 97yQ== X-Gm-Message-State: AO0yUKW7Dh4m0i0vbsfmqEZQOMeuEk0ng4Xj4Cc3nPZgi8f99MOKGMNp +HcxnxFPerrZr6mP/EtwwvHZzw== X-Google-Smtp-Source: AK7set8pa4xz7QNFXV69H5JIoXX7JugIG/yDsBFNDd7qPnKqjlriqHfN4ZqDe6euKY8jh4xkt8Et2w== X-Received: by 2002:a05:6a20:c10f:b0:d5:e2cb:6100 with SMTP id bh15-20020a056a20c10f00b000d5e2cb6100mr24809569pzb.49.1680253861353; Fri, 31 Mar 2023 02:11:01 -0700 (PDT) Received: from [192.168.1.27] ([182.77.80.28]) by smtp.gmail.com with ESMTPSA id t126-20020a635f84000000b004fb26a80875sm1160666pgb.22.2023.03.31.02.10.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 31 Mar 2023 02:11:01 -0700 (PDT) Message-ID: Date: Fri, 31 Mar 2023 14:41:14 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 X-Mozilla-News-Host: news://news.gmane.io:119 Content-Language: en-US From: Vineet Gupta To: Jeff Law , Kito Cheng , Palmer Dabbelt Cc: gcc@gcc.gnu.org Subject: ideas on PR/109279 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=1.7 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,KAM_NUMSUBJECT,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 ! Thx, -Vineet