чт, 20 авг. 2026 г. в 12:52, Georg-Johann Lay <[email protected]>: > > Am 20.08.26 um 00:51 schrieb Roger Sayle: > > > > This patch is a revision of my previous patch to use add_optab in > > the expansion of bitreverse which improves code generation on x86, > > cris, riscv, parisc, sh and possibly other targets. > > https://gcc.gnu.org/pipermail/gcc-patches/2026-August/726901.html > > > > This patch addresses Jeff Law's (and Georg-Johann Lay's earlier) > > concerns that targets without a shift-add instruction don't benefit > > from the use of PLUS, and may potentially hurt optimization. Alas > > it's not sufficient to check whether a target supports an addsi3 > > optab, and even (the default) rtx_costs can't be relied upon. > > The solution here is to introduce an aop_optab (for any_or_plus) > > to allow a backend complete control over choices of PLUS vs. IOR > > vs. XOR. For example, x86_64 would prefer IOR (or XOR) over PLUS > > for V1TImode. As a worked example, this patch defines an aop_optab > > for AVR to always use PLUS. > > > > Interestingly, testing this functionality on AVR is fairly difficult, > > as the backend provides expansions for bitreverse, bswap and rotate, > > i.e. all the obvious places where aop_optab would be used. Fortunately, > > I was able to identify an optimization in store_fixed_bitfield_1 that > > affects code generation (on avr-elf). > > > > Consider the test case: > > > > typedef struct { > > int a : 1; > > int b : 1; > > int c : 16; > > int d : 14; > > } S; > > > > S foo(S x, unsigned char y) > > { > > x.c = y; > > return x; > > } > > > > Currently, with -O2 x86_64 generates (both sall and orl): > > > > foo: andl $-262141, %edi > > movzbl %sil, %esi > > sall $2, %esi > > movl %edi, %eax > > orl %esi, %eax > > ret > > > > with this revised patch to make use of aop_optab, we now get: > > > > foo: movzbl %sil, %esi > > andl $-262141, %edi > > leal (%rdi,%rsi,4), %eax > > ret > > > > On avr-elf, without the avr.md change we would get (a PLUS): > > > > foo: mov r18,r20 > > lsl r18 > > lsl r18 > > andi r22,lo8(3) > > add r22,r18 > > clr r23 > > bst r20,6 > > bld r23,0 > > bst r20,7 > > bld r23,1 > > andi r24,lo8(-4) > > ret > > > > But with avr.md's define_expand for aop<mode>3 we restore the original: > > > > foo: mov r18,r20 > > lsl r18 > > lsl r18 > > andi r22,lo8(3) > > or r22,r18 > > clr r23 > > bst r20,6 > > bld r23,0 > > bst r20,7 > > bld r23,1 > > andi r24,lo8(-4) > > ret > > Hi Roger, > > I think the change is ok for avr, though I am not a maintainer > and hence I can't approve. > > In the above avr code, AND and OR have exactly the same resource > consumption and operand capabilities.
I agree with Johann. Approved for avr. Denis
