Re: how to find an unrecognizable insn

[Jim Wilson <wilson at specifixinc dot com>]

Shinpei Kato wrote:
> (insn 71 25 26 0 ../../../../../gcc-3.4.0/newlib/libc/stdlib/erand48.c:22 (set (subreg:HI (reg:SI 34 $f2) 2)
>         (mem:HI (reg/v/f:SI 16 $16 [orig:175 xseed ] [175]) [8 S2 A16])) -1 (nil)
>     (nil))

There are a number of possible explanations.  We may not be able to help
much without more detailed info.

The first step is to figure out why the instruction doesn't match.  This
is an HImode (16-bit) load from memory into $f2 which is presumably an
FP register.  Most targets don't support sub-word loads into FP regs.

The next step is to figure out where it came from.  Use -da to generate
RTL dumps after every optimization pass, and find the first dump file to
contain this, or the last dump file which is only partially emitted.  My
guess is that it is generated during reload, which means either it will
first appear in the .greg dump file, or else the .greg dump file will be
incomplete (because the compiler died before finishing).

Then you try to figure out why this happened.  I do not have enough info
to even make a guess here.  You need to look at the RTL before reload,
you need to look at what reload did to the RTL, you need to look at the
mov patterns in the md file, and you may also need to look at constraint
definitions, register class definitions, etc.  In short, we need a lot
more info to help you further.  This insn was presumably generated as a
reload, which means you should be able to figure out what the original
insn that needed reloading was, and get the list of reloads generated
for that insn, which will explain why this particular insn was emitted.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com