http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51241
--- Comment #1 from Kazumoto Kojima <kkojima at gcc dot gnu.org> 2011-11-21
01:52:22 UTC ---
Please put the description of the problem into the trail itself
instead of attachment next time.
The problem looks to be splitted into several issues.
> mov.b @r4+,r3 ! 40 *extendqisi2_compact_mem_inc
> extu.b r3,r3 ! 41 *zero_extendqisi2_compact <--- extu.b r3, r0
> mov r3,r0 ! 75 movsi_ie/2 <--- ??
This mov insn is generated with reload. After all, SH's and #imm,*
would be too restrictive.
> exts.b r3,r3 ! 50 *extendqisi2_compact <--- ??
> and #127,r0 ! 45 *andsi3_compact/1 <--- makes extu.b useless
> cmp/pz r3 ! 51 cmpgesi_t/2
As you pointed out, if cmp/pz is placed at just after mov.b insn,
exts.b is not required. I don't know whether such pass exists or not.
> mov.l @r4,r1 ! 7 movsi_ie/7 [length = 2]
> swap.w r1,r1 ! 13 rotlsi3_16 [length = 2]
> exts.w r1,r1 ! 14 *extendhisi2_compact/1 [length = 2]
> rts ! 21 *return_i [length = 2]
> mov.b r1,@r5 ! 10 *movqi/4 [length = 2]
The sequence of swap.w and exts.w are generated ashrsi2_16 insn
and its splitter. exts.w could be removed by the combine pass,
though the split is done after combine. Perhaps with replacing
that insn and splitter with an expand like
(define_expand "ashrsi2_16"
[(set (match_operand:SI 0 "arith_reg_dest" "")
(rotate:SI (match_operand:SI 1 "arith_reg_operand" "")
(const_int 16)))
(set (match_dup 0) (sign_extend:SI (match_dup 2)))]
"TARGET_SH1"
"operands[2] = gen_lowpart (HImode, operands[0]);")
the combine will do the work.
> negc r1,r1 ! 10 negc [length = 2]
> extu.b r1,r0 ! 12 *zero_extendqisi2_compact [length = 2]
Again, usually the combine pass can remove such extu.b.
Perhaps negc has a pattern
[(set (match_operand:SI 0 "arith_reg_dest" "=r")
(neg:SI (plus:SI (reg:SI T_REG)
(match_operand:SI 1 "arith_reg_operand" "r"))))
(set (reg:SI T_REG)
(ne:SI (ior:SI (reg:SI T_REG) (match_dup 1))
(const_int 0)))]
which would be too complex for combine.
