redundant divmodsi4 not optimized away

[Greg McGary]

On 04/28/10 05:58, Michael Matz wrote:

> On Tue, 27 Apr 2010, Greg McGary wrote:
>    
>> (define_insn "*udivmodsi4_libcall"
>>    [(set (reg:SI 4)
>>      (udiv:SI (reg:SI 1)
>>           (reg:SI 2)))
>>     (set (reg:SI 1)
>>      (umod:SI (reg:SI 1)
>>           (reg:SI 2)))
>>     (clobber (reg:SI 2))
>>     (clobber (reg:SI 3))
>>     (clobber (reg:CC CC_REGNUM))
>>     (clobber (reg:SI RETURN_POINTER_REGNUM))]
>>    ""
>>    "call\\t__udivmodsi4"
>>    [(set_attr "length"    "4")])
>>      
> So, this pattern uses r2 and clobbers r2+r3.  Two calls in a row can't be
> eliminated because the execution of one destroys one operand of the other
> as far as GCC knows, and the necessary copies to reload the correct value
> into r2 before the second call might confuse combine/CSE/DCE/whatever.  At
> least that would be my theory to start from :)
>    

The libcall insn above appears only after reload, as the result of a 
split.  All the CSE passes occur before reload when the insn pattern is 
this:

   [(set (match_operand:SI 0 "gen_reg_operand" "=r")
     (udiv:SI (match_operand:SI 1 "gen_reg_operand" "r")
          (match_operand:SI 2 "gen_reg_operand" "r")))
    (set (match_operand:SI 3 "gen_reg_operand" "=r")
     (umod:SI (match_dup 1)
          (match_dup 2)))
    (clobber (reg:SI 1))
    (clobber (reg:SI 2))
    (clobber (reg:SI 3))
    (clobber (reg:SI 4))
    (clobber (reg:CC CC_REGNUM))
    (clobber (reg:SI RETURN_POINTER_REGNUM))]

G