[Bug target/82931] Missing Optimization for Bit-Transfer (AVR Target)

["gjl at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82931

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #42575|0                           |1
        is obsolete|                            |

--- Comment #3 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
Created attachment 43134
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43134&action=edit
Valid C++ test case

Confirmed for current trunk and the attached test case with

$ avr-g++ pr82931.cc -Os -mmcu=avr4 -fdump-rtl-combine-details && cat
pr82931.cc.265r.combine

The patterns are just getting too complicated due to the involved MEMs:

Failed to match this instruction:
(set (zero_extract:QI (mem:QI (reg/v/f:HI 50 [ dst ]) [0 *dst_11(D)+0 S1 A8])
        (const_int 1 [0x1])
        (const_int 4 [0x4]))
    (lshiftrt:QI (reg:QI 52)
        (const_int 4 [0x4])))

Note that the avr BE provides zero_extract, but not with MEM operands:

;; Insert bit $2.$3 into $0.$1
(define_insn "*insv.shiftrt"
  [(set (zero_extract:QI (match_operand:QI 0 "register_operand"    "+r")
                         (const_int 1)
                         (match_operand:QI 1 "const_0_to_7_operand" "n"))
        (any_shiftrt:QI (match_operand:QI 2 "register_operand"      "r")
                        (match_operand:QI 3 "const_0_to_7_operand"  "n")))]
  ""
  "bst %2,%3\;bld %0,%1"
  ...

Adding versions with MEM operand would explode the BEs complexity, and such
patches are usually rejected because of that.

Instead, insn combiner should try versions that use the MEMs as a split point
and try REGs instead.