diff options
author | Jeff Law <jlaw@ventanamicro.com> | 2025-04-18 12:19:30 -0600 |
---|---|---|
committer | Jeff Law <jlaw@ventanamicro.com> | 2025-04-18 12:21:23 -0600 |
commit | 45a1038f3ca6ddceb8d159ccba6d99ed61951472 (patch) | |
tree | e696df4f328b8894b91d1bb4dc96b2cef962d1ba /libjava/gnu/java | |
parent | b986ed16c2546674256b8c892541a8fdb6a97202 (diff) | |
download | gcc-45a1038f3ca6ddceb8d159ccba6d99ed61951472.zip gcc-45a1038f3ca6ddceb8d159ccba6d99ed61951472.tar.gz gcc-45a1038f3ca6ddceb8d159ccba6d99ed61951472.tar.bz2 |
[RISC-V] Fix missed bext discovery
RISC-V has the ability to extract a single bit out of a register from a fixed
or variable position.
While looking at 502.gcc a little while ago I realize that we failed to use
bext inside bitmap_bit_p for its return value.
The core "problem" is that the RISC-V does not define SHIFT_COUNT_TRUNCATED
(for good reasons). As a result the target is largely responsible for handling
elimination of shift count/bit position masking.
There's a follow-up patch I've been working on with an intern to improve
detection of bext in more cases. This one stands independently though and is
probably the most important of the missed cases.
Will push to the trunk assuming pre-commit testing is green. It's already been
through my tester as well as Ventana's internal testing.
gcc
* config/riscv/bitmanip.md (*bext<mode>_mask_pos): New pattern
for extracting a single bit at masked bit position.
gcc/testsuite
* gcc.target/riscv/bext-ext-2.c: New test
Diffstat (limited to 'libjava/gnu/java')
0 files changed, 0 insertions, 0 deletions