This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]