This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: ivopts-caused "unrecognized insn"
- From: Ian Lance Taylor <iant at google dot com>
- To: Cynbe ru Taren <cynbe at muq dot org>
- Cc: gcc-help at gcc dot gnu dot org
- Date: Wed, 26 Sep 2012 14:26:33 -0700
- Subject: Re: ivopts-caused "unrecognized insn"
- References: <E1TGxxO-00025H-9I.plugh@laurel.muq.org>
On Wed, Sep 26, 2012 at 1:11 PM, Cynbe ru Taren <cynbe@muq.org> wrote:
>
> 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?
You can generate a different insn sequence if the constant is too large.
> Is it that match_scratch really works only in define_expand and
> not in define_insn, say?
No, match_scratch can work. But the scheduler won't be able to see
the sequence of instructions, and neither will CSE, etc.
> 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()?
No. A define_expand generates one or more insns that must match
define_insn patterns. Your define_insn pattern will use a constraint
that only permits constants that are in range for the instruction.
Ian