ivopts-caused "unrecognized insn"

[Cynbe ru Taren]

Ian Lance Taylor <iant@google.com> writes: 
 
> No, addsi3 is a named pattern and you could and should use define_expand. 
> 
> Ian 

That is an excellent hint -- thank you!

Might I ask what the advantage of define_expand is in this case?

Is it that match_scratch really works only in define_expand and
not in define_insn, say?

Obviously, I want to continue generating the simple add-immediate
assembly

    "add%i2\\t%0, %1, %z2"

instruction in the 99.999% of cases where the "ivopts" pass does not
kick in and make the rtx unrecognizable by changing the immediate constant
to be out of addi's 16-bit immediate-constant range -- I only want to retreat
to a clumsy three-instruction sequence when ivopts forces me to do so.

Since define_expands are processed long before the "ivopts" pass runs,
I don't see that I can choose between the one- and three-instruction
sequences in the define_expand itself.

And if I want to generate the single-instruction form 99.999% of
the time, using define_expand to actually expand into multiple
insns seems chancy -- isn't there a risk that the insns might get
re-ordered such that they don't get combined back into a
single-instruction solution in combine()?

Many thanks!

 -- Cynbe