This is the mail archive of the gcc-help@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: ivopts-caused "unrecognized insn"


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


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