Tomas Svensson wrote:
On 19 Sep 2007 07:54:14 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
gcse will never convert a recognizable insn into an unrecognizable
insn.
Ok. Do you know of any other reasons why this particular optimization
switch would cause this problem?
There are millions of reasons why there might be a problem. You need to
do some debugging to analyze the problem. I think the fact that gcse
create an insn that caused combine to choke is probably not relevant.
Step through combine to see what is going on. add_clobbers should only
be called for an insn number that contains clobbers. This is
conditional on num_clobbers_to_add, which is set in a recog() call. So
step through recog to see why it is being set. This is the variable
pnum_clobbers in recog, in the file insn-recog.c. insn-recog.c is
created by genrecog.c, but you want to look there only as a last resort.
No one else can do this analysis for you as no one else has a copy of
your port.
But this should not need a matching insn, since it ends in a DONE;,
right? Or am I missing something again?
This is correct. You need a define_insn to match all RTL emitted during
the RTL expansion phase. However, when you have a define_expand which
uses a minimal RTL template just to indicate the number of operands, and
which does not actually emit this RTL template into any insn, then you
do not need a define_insn to match this RTL template. You do need a
define_insn to match the RTL emitted by the expand_branch function though.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com