------- Comment #6 from uros at kss-loka dot si 2005-10-28 06:05 -------
(In reply to comment #5)
> The realy problem here is that the xor is produced after reload and is really
> only done on some x86 targets.
>
This happens in following peephole2 pattern:
;; Don't move an immediate directly to memory when the instruction
;; gets too big.
(define_peephole2
[(match_scratch:SI 1 "r")
(set (match_operand:SI 0 "memory_operand" "")
(const_int 0))]
"! optimize_size
&& ! TARGET_USE_MOV0
&& TARGET_SPLIT_LONG_MOVES
&& get_attr_length (insn) >= ix86_cost->large_insn
&& peep2_regno_dead_p (0, FLAGS_REG)"
[(parallel [(set (match_dup 1) (const_int 0))
(clobber (reg:CC FLAGS_REG))])
(set (match_dup 0) (match_dup 1))]
"")
The problem is, that peephole2 optimizations happens very late, and no further
RTL pass can eliminate redundant loads.
Do we need a post-peephole2 gcse pass? :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19922
