This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: how to find an unrecognizable insn
Thank you for replying,
I've worked with this problem for a week. The situation hasn't been
proceeded but a little bit changed.
Now I'm looking up other architeture's machine discriptions.
The following your explanation is really helpful for me which is a
newbie to porting gcc. I have to do with my final reports, exercise and
exams at uni from now on. I'm gonna post a message again if I can't
still solve the problem.
Thanks,
Shinpei
On Mon, 12 Jul 2004 14:57:00 -0700
Jim Wilson <wilson@specifixinc.com> wrote:
> > 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
>