aboutsummaryrefslogtreecommitdiff
path: root/libgcc
diff options
context:
space:
mode:
authorJeff Law <jlaw@ventanamicro.com>2024-05-06 15:27:43 -0600
committerJeff Law <jlaw@ventanamicro.com>2024-05-06 15:27:43 -0600
commit975bb17e2f6bc90d366237ab1c5dc9b8df2dee69 (patch)
treed6669a74deb4e75855539d7a5dc9ee159db9e4fb /libgcc
parent53026cbf08889d00fed34d8667796d22ef8554cf (diff)
downloadgcc-975bb17e2f6bc90d366237ab1c5dc9b8df2dee69.zip
gcc-975bb17e2f6bc90d366237ab1c5dc9b8df2dee69.tar.gz
gcc-975bb17e2f6bc90d366237ab1c5dc9b8df2dee69.tar.bz2
So another constant synthesis improvement.
In this patch we're looking at cases where we'd like to be able to use lui+slli, but can't because of the sign extending nature of lui on TARGET_64BIT. For example: 0x8001100000020UL. The trunk currently generates 4 instructions for that constant, when it can be done with 3 (lui+slli.uw+addi). When Zba is enabled, we can use lui+slli.uw as the slli.uw masks off the bits 32..63 before shifting, giving us the precise semantics we want. I strongly suspect we'll want to do the same for a set of constants with lui+add.uw, lui+shNadd.uw, so you'll see the beginnings of generalizing support for lui followed by a "uw" instruction. The new test just tests the set of cases that showed up while exploring a particular space of the constant synthesis problem. It's not meant to be exhaustive (failure to use shadd when profitable). gcc/ * config/riscv/riscv.cc (riscv_integer_op): Add field tracking if we want to use a "uw" instruction variant. (riscv_build_integer_1): Initialize the new field in various places. Use lui+slli.uw for some constants. (riscv_move_integer): Handle slli.uw. gcc/testsuite/ * gcc.target/riscv/synthesis-2.c: New test.
Diffstat (limited to 'libgcc')
0 files changed, 0 insertions, 0 deletions