public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Vineet Gupta <vineetg@rivosinc.com>
To: Jeff Law <jeffreyalaw@gmail.com>,
	Kito Cheng <kito.cheng@sifive.com>,
	Palmer Dabbelt <palmer@rivosinc.com>
Cc: gcc@gcc.gnu.org
Subject: ideas on PR/109279
Date: Fri, 31 Mar 2023 14:41:14 +0530	[thread overview]
Message-ID: <ae6d67c8-b350-6098-255e-160f5f9521d1@rivosinc.com> (raw)

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

             reply	other threads:[~2023-03-31  9:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-31  9:11 Vineet Gupta [this message]
2023-03-31 13:34 ` Jeff Law
2023-03-31 14:13   ` Kito Cheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ae6d67c8-b350-6098-255e-160f5f9521d1@rivosinc.com \
    --to=vineetg@rivosinc.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    --cc=kito.cheng@sifive.com \
    --cc=palmer@rivosinc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).