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
