xtensa PR65730

[augustine.sterling@gmail.com]

On Fri, Apr 10, 2015 at 1:18 PM, Max Filippov <jcmvbkbc@gmail.com> wrote:
> 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?

I'm not completely sure, but I think you want to use OPTAB_LIB as you
described above, and eliminate the TARGET_MUL32 condition in the
pattern.