https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124901
Uroš Bizjak <ubizjak at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |WONTFIX
Status|ASSIGNED |RESOLVED
--- Comment #7 from Uroš Bizjak <ubizjak at gmail dot com> ---
OTOH, late_combine after peephole2 will combine back instructions that are
split on purpose, e.g:
;; Don't compare memory with zero, load and use a test instead.
(define_peephole2
[(set (match_operand 0 "flags_reg_operand")
(match_operator 1 "compare_operator"
[(match_operand:SI 2 "memory_operand")
(const_int 0)]))
(match_scratch:SI 3 "r")]
"optimize_insn_for_speed_p () && ix86_match_ccmode (insn, CCNOmode)"
[(set (match_dup 3) (match_dup 2))
(set (match_dup 0) (match_op_dup 1 [(match_dup 3) (const_int 0)]))])
1084: dx:SI=[`a']
1085: flags:CCZ=cmp(dx:SI,0)
REG_DEAD dx:SI
47: pc={(flags:CCZ==0)?L591:pc}
REG_BR_PROB 16566481
rescanning insn with uid = 1085.
verify found no changes in insn with uid = 1085.
deleting insn with uid = 1084.
1085: flags:CCZ=cmp([`a'],0)
47: pc={(flags:CCZ==0)?L591:pc}
REG_BR_PROB 16566481
so the idea of having late_combine after peephole2 is not that great after all.
