RFC: PR rtl-optimization/44695: [4.6 Regression] ice in simplify_subreg, at simplify-rtx.c:5117

On Wed, Jun 30, 2010 at 4:53 AM, Paolo Bonzini <bonzini@gnu.org> wrote:
> On 06/29/2010 09:12 PM, H.J. Lu wrote:
>>
>> After revision 161329, x86 backend may generate:
>>
>> (ior:HI (ashift:HI (zero_extend:HI (umod:QI (reg:HI 68)
>>                 (reg:QI 61 [ D.2750 ])))
>>         (const_int 8 [0x8]))
>>     (zero_extend:HI (udiv:QI (reg:HI 68)
>>             (reg:QI 61 [ D.2750 ]))))
>>
>> combine calls simplify_subreg and leads to
>>
>> #2  0x00000000009ad621 in simplify_subreg (outermode=HImode,
>>     op=0x7ffff7facd40, innermode=QImode, byte=0)
>>     at /space/rguenther/src/svn/trunk/gcc/simplify-rtx.c:5116
>> 5116      gcc_assert (GET_MODE (op) == innermode
>> 5117                  || GET_MODE (op) == VOIDmode);
>> (gdb) call debug_rtx (op)
>> (reg:HI 68)
>>
>> This patch adds simplify_gen_subreg_for_combine to deal with invalid
>> combination of outermode, op and innermode generated by combine.  Any
>> comments?
>
> I commented in the PR about the correct fix.  Sorry for not spotting it in
> the review (I had a doubt, but in the end I didn't look it up and left the
> final call to Uros...).
>

Here is a patch to change 8bit div/mod to HImode.  OK for trunk?

Thanks.

This is wrong. GCC may use this for a 16 to 8 bit division and cause a
divide overflow.

My comment in the PR is based on how GCC handles extension of the
dividend for 16/32/64 bit operands.

Paolo

On Wed, Jun 30, 2010 at 11:59 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
> This is wrong. GCC may use this for a 16 to 8 bit division and cause a
> divide overflow.

The old divide pattern is

(define_insn "<u>divqi3"
  [(set (match_operand:QI 0 "register_operand" "=a")
        (any_div:QI
          (match_operand:HI 1 "register_operand" "0")
          (match_operand:QI 2 "nonimmediate_operand" "qm")))
   (clobber (reg:CC FLAGS_REG))]
  "TARGET_QIMODE_MATH"
  "<sgnprefix>div{b}\t%2"
  [(set_attr "type" "idiv")
   (set_attr "mode" "QI")])

Why is it OK to have HImode on operand 1? The current one is

(define_insn "divmodhiqi3"
  [(set (match_operand:HI 0 "register_operand" "=a")
        (ior:HI
          (ashift:HI
            (zero_extend:HI
              (mod:QI (match_operand:HI 1 "register_operand" "0")
                      (match_operand:QI 2 "nonimmediate_operand" "qm")))
            (const_int 8))
          (zero_extend:HI (div:QI (match_dup 1) (match_dup 2)))))
   (clobber (reg:CC FLAGS_REG))]
  "TARGET_QIMODE_MATH"
  "idiv{b}\t%2"
  [(set_attr "type" "idiv")
   (set_attr "mode" "QI")])

Why isn't HImode on operand 1 OK?

> My comment in the PR is based on how GCC handles extension of the
> dividend for 16/32/64 bit operands.
>

Your suggestion generate a pattern unsupported by hardware
before reload and introduces an extra register move during split
to fix it.

> Why isn't HImode on operand 1 OK?

Because modes don't match between the div and its operands.

>> My comment in the PR is based on how GCC handles extension of the
>> dividend for 16/32/64 bit operands.
>>
>
> Your suggestion generate a pattern unsupported by hardware
> before reload

That's what 16/32/64 bit operands do too

(define_expand "divmod<mode>4"
   [(parallel [(set (match_operand:SWIM248 0 "register_operand" "")
                    (div:SWIM248
                      (match_operand:SWIM248 1 "register_operand" "")
                      (match_operand:SWIM248 2 "nonimmediate_operand" "")))
               (set (match_operand:SWIM248 3 "register_operand" "")
                    (mod:SWIM248 (match_dup 1) (match_dup 2)))
               (clobber (reg:CC FLAGS_REG))])]
   ""
   "")


> and introduces an extra register move during split to fix it.

I think you mean one extra extension?  That's possible, though it could 
be fixed in combine using nonzero_bits or num_sign_bit_copies.

Anyway, can you please post the patch and the result?  I think you 
should go one step at a time and first fix this bug, then optimize it.

Paolo