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.
