aboutsummaryrefslogtreecommitdiff
path: root/gcc/expr.cc
diff options
context:
space:
mode:
authorJeff Law <jlaw@ventanamicro.com>2024-05-13 17:37:46 -0600
committerJeff Law <jlaw@ventanamicro.com>2024-05-13 17:37:46 -0600
commit158aa1b65ce29d5e58182782de66292c51774d71 (patch)
tree14216c27e3307e291d7e56b2f9bbe3ae910d3355 /gcc/expr.cc
parentdf15eb15b5f820321c81efc75f0af13ff8c0dd5b (diff)
downloadgcc-158aa1b65ce29d5e58182782de66292c51774d71.zip
gcc-158aa1b65ce29d5e58182782de66292c51774d71.tar.gz
gcc-158aa1b65ce29d5e58182782de66292c51774d71.tar.bz2
[to-be-committed,RISC-V] Improve AND with some constants
If we have an AND with a constant operand and the constant operand requires synthesis, then we may be able to generate more efficient code than we do now. Essentially the need for constant synthesis gives us a budget for alternative ways to clear bits, which zext.w can do for bits 32..63 trivially. So if we clear 32..63 via zext.w, the constant for the remaining bits to clear may be simple enough to use with andi or bseti. That will save us an instruction. This has tested in Ventana's CI system as well as my own. I'll wait for the upstream CI tester to report success before committing. Jeff gcc/ * config/riscv/bitmanip.md: Add new splitter for AND with a constant that masks off bits 32..63 and needs synthesis. gcc/testsuite/ * gcc.target/riscv/zba_zbs_and-1.c: New test.
Diffstat (limited to 'gcc/expr.cc')
0 files changed, 0 insertions, 0 deletions