This is the mail archive of the gcc@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: xtensa PR65730


On Fri, Apr 10, 2015 at 10:51 PM, augustine.sterling@gmail.com
<augustine.sterling@gmail.com> wrote:
> On Fri, Apr 10, 2015 at 12:15 PM, Max Filippov <jcmvbkbc@gmail.com> wrote:
>> Then configuration w/o multiplication should call helper at -O0 and
>> use shift at higher optimization levels?
>
> That is what I would expect.

Ok, then I see why this doesn't happen: mulsi3 pattern matching is
conditional on TARGET_MUL32, so when TARGET_MUL32 ==0 and
expand_simple_binop emits a call to a helper it's not considered
mulsi3, it's just a call:

(call_insn/u 17 15 18 3 (set (reg:SI 10 a10)
        (call (mem:SI (reg:SI 56) [0  S4 A32])
            (const_int 0 [0])))
libstdc++-v3/include/bits/atomic_base.h:287 51 {call_value_internal}
     (expr_list:REG_CALL_DECL (symbol_ref:SI ("__mulsi3") [flags 0x41])
        (expr_list:REG_EH_REGION (const_int -2147483648 [0xffffffff80000000])
            (nil)))
    (expr_list (use (reg:SI 11 a11))
        (expr_list (use (reg:SI 10 a10))
            (nil))))

vs.

(insn 15 14 16 3 (set (reg:SI 57)
        (mult:SI (reg:SI 55)
            (reg:SI 56))) libstdc++-v3/include/bits/atomic_base.h:287 5 {mulsi3}
     (nil))

How can we have a mulsi3 pattern that don't get expanded until it's
optimized, and only gets expanded to a call if it couldn't be optimized?

-- 
Thanks.
-- Max


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