This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: How to deal with unrecognizable RTL code
- From: Jeff Law <law at redhat dot com>
- To: daniel tian <daniel dot xntian at gmail dot com>
- Cc: Dave Korn <dave dot korn dot cygwin at googlemail dot com>, gcc at gcc dot gnu dot org, peng dot zheng at mavrixtech dot com, thomas dot liau at mavrixtech dot com
- Date: Thu, 25 Jun 2009 12:44:08 -0600
- Subject: Re: How to deal with unrecognizable RTL code
- References: <121fadb80906240316y68a8c132yd254db302e246b37@mail.gmail.com>
daniel tian wrote:
>
> it will be called in GO_IF_LEGITIMATE_ADDRESS, and
> LEGITIMIZE_RELOAD_ADDRESS. So like the following unrecognizable RTL
> has gone.
>
I would _strongly_ recommend you initially develop your port without
defining LEGITIMIZE_RELOAD_ADDRESS. Let reload work in the way it was
intended, particularly since I haven't seen anything to-date which would
indicate your chip has characteristics which reload can't handle.
Once your port is working well, you can go back and define
LEGITIMIZE_RELOAD_ADDRESS to optimize handling of reloads -- and because
your port was working prior to defining LEGITIMIZE_RELOAD_ADDRESS any
new failures are most likely due to an improper definition of
LEGITIMIZE_RELOAD_ADDRESS (which is easy to do given you have to know
how reload works to properly implement LEGITIMIZE_RELOAD_ADDRESS).
[ ... ]
>
> The RTL is at the beginning of the function, and R5 is used to pass
> parameter. So I think maybe should also trace the parameter passing
> function.
>
Again, the best thing you can do is find the first dump file where these
problematical insns exist. That would be a huge step forward.
jeff