Re: ivopts-caused "unrecognized insn"

[Ian Lance Taylor <iant at google dot com>]

On Wed, Sep 26, 2012 at 4:09 PM, Cynbe ru Taren <cynbe@muq.org> wrote:
>
> 1) Immediate constant is in range (i.e., fits in signed 16-bit field)
>    at RTL generation time so the tried-and-true rule
>
>       (define_insn "addsi3"
>         [(set (match_operand:SI 0 "register_operand"      "=r,r")
>           (plus:SI (match_operand:SI 1 "register_operand" "%r,r")
>                   (match_operand:SI 2 "arith_operand"      "r,I")))]
>         ""
>         "add%i2\\t%0, %1, %z2"
>         [(set_attr "type" "alu")])
>
>    fires in the expectation of generating an "addi" with 16-bit immediate constant.

Rename that to *addsi3.  Remove the second alternative.  Write a new
define_expand named addsi3 that looks at the second operand; if it is
a constant that is too large, write out the three instruction
sequence.

> 2) During the "ivopts" pass, the constant is rewritten to no longer fit in 16 bits.
>    This is rare -- I currently only know of two cases of this happening in the wild.
>    I can post the transformation details if required, but all that really matters
>    for current purposes is that in fact it happens.

If you do the above, ivopts ought to go back through addsi3 to get the
three insn sequence.  It shouldn't rewrite the constant in place,
because that owuld produce an unrecognized insn.

> Are you saying that I can include logic in my define_expand which will
> correctly predict that "ivopts" will modify the constant to no longer
> fit in 16 bits, and expand an alternate suitable insn sequence based on
> that foreknowledge?  (That seems like a tall order! :-)
>
> Or are you saying that there is some way to arrange for define_expand
> logic to run after the "ivopts" pass and before the "vregs" pass, so
> as to re-select appropriate RTL based on the results of the "ivopts"
> pass modifications to the RTL?

ivopts ought to run the define_expand for you.

Ian