On 9/3/26 3:55 AM, Roger Sayle wrote:
This patch is a revision of my previous patch to use add_optab in
the expansion of bitreverse and store_fixed_bitfield which improves
code generation on x86, cris, riscv, parisc, sh and possibly other
targets.
https://gcc.gnu.org/pipermail/gcc-patches/2026-August/728199.html
The AVR backend change has been approved by the AVR maintainers,
and a patch committed to avoid issues on AArch64, so all that
remains are the middle-end pieces.
This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32}
with no new failures. Ok for mainline?
2026-09-03 Roger Sayle <[email protected]>
gcc/ChangeLog
* expmed.cc (store_fixed_bit_field_1): Use new aop_optab when
writing a value into a fixed size bitfield of a structure.
* optabs.cc (expand_binop): If target doesn't provide a suitable
aop<mode>3 instruction, intelligently use PLUS or IOR instead.
(expand_binop): For rotations, use aop_optab to select AOP
implementation instead of hard-coding add_optab.
(expand_bitreverse): Likwise, Use aop_optab instead of ior_optab
when composing swapped bits and nibbles (allows use of shift_add).
* optabs.def (aop_optab): New named optab for any_or_plus.
* rtl.def (AOP): New RTX code to capture any_or_plus semantics.
* config/avr/avr.md (aop<mode>3): New define_expand to specify
that IOR should always be used to implement any_or_plus (AOP).
gcc/testsuite/ChangeLog
* gcc.target/i386/builtin-bitreverse-1.c: New test case.
OK. I'll resist the ever-so-slight temptation to go look at the code
generation for RISC-V when we don't turn on the "B" extension (which has
the shadd insns). In theory we're still better off steering towards
"add" rather than "ior" because "add" is more likely to be
compressable. Compressability is based on the registers being used and
"add" allows a wider set than "ior".
Jeff
