Re: Unrecognizable insn

[James E Wilson <wilson at specifixinc dot com>]

Shinpei Kato wrote:
> (insn 94 35 36 0
> ../../../../../gcc-3.4.0/newlib/libc/stdlib/erand48.c:22 (set
> (subreg:HI (reg:SI 32 $f0) 2) (mem:HI (reg/v/f:SI 17 $17 [orig:175
> xseed ] [175]) [5 S2 A16])) -1 (nil) (nil))

Looking at this, we can see that this insn 94 was emitted in between
insns 35 and 36.  Since it died before completing the greg dump, that
implies that this was a reload problem, and this must have either been
an output reload for insn 35, or else an input reload for insn 36.
Looking at the greg dump, we see that we did emit reloads for insn 36.

So you need to look closer at insn 36.  You can see it in the lreg dump
which comes immediately before the greg dump.  You need to figure out
why reloads are being generated for it, and why we are generating
invalid instructions for the reloads.

It isn't hard to see why there are reloads though.   I seriously doubt
that your target supports HImode loads into FP registers.  This is a
very rare operation.  Thus we need to fix it by loading the HImode value
into a scratch, and then copy the scratch into the target FP reg.  Or
alternatively, prevent the paradoxical subreg from being accepted as an
operand in the first place.

I suspect this works for the mips port because it defines
INSN_SCHEDULING which as a side effect rejects paradoxical subregs
before reload.  This is an old workaround for an old bug, which really
should be fixed some day.  Looks like Zack just took a stab at this, and
ran into problems.   Meanwhile, enabling instruction scheduling for your
target might fix it, even if you don't have anything to schedule.  Or
you could define your own predicates instead of relying on the default
behaviour of register_operand.

Otherwise, you need to teach reload how to make this work.  This may
require use of secondary reloads, to allocate a scratch general register
to do the load into, and then you can copy the scratch reg to an FP reg.
 See SECONARY_RELOAD_CLASS, SECONDARY_INPUT_RELOAD_CLASS,
SECONDARY_OUTPUT_RELOAD_CLASS.  Just return GENERAL_REGS or an
equivalent class when trying to reload an HImode MEM into an FP reg.

There may also be other ways to solve this.  You will have to step
through reload and learn a little bit about how it works, and then you
will see all of the ways that it can be tweaked to change its behaviour.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com