This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PR middle-end/30191 (was: [PATCH] Fix PR middle-end/28690, indexed load/store performance + reload bug)
- From: Peter Bergner <bergner at vnet dot ibm dot com>
- To: Michael Matz <matz at suse dot de>
- Cc: Ulrich Weigand <ulrich dot weigand at de dot ibm dot com>, Andrew Pinski <pinskia at gmail dot com>, David Edelsohn <dje at makai dot watson dot ibm dot com>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 13 Dec 2006 14:07:49 -0600
- Subject: Re: PR middle-end/30191 (was: [PATCH] Fix PR middle-end/28690, indexed load/store performance + reload bug)
- References: <200612131811.kBDIBCpW026087@d12av02.megacenter.de.ibm.com> <Pine.LNX.4.64.0612131914390.29962@wotan.suse.de>
On Wed, 2006-12-13 at 19:21 +0100, Michael Matz wrote:
> Indeed, that's unfortunate. I can only think of not calling recog()
> during reload_in_progress, i.e. after the pseudo reg rtl is overwritten
> with the hard-reg they got. Conceptually that should nearly work, as
> reload doesn't really change the form of instruction, it only replaces
> some operand by registers, which shouldn't change the recognizability (as
> long as the constraints will do the right thing).
>
> Unfortunately that's not the whole truth, and sometimes reload does change
> the insn structure which theoretically would require a recog. One could
> require for all changes imaginable by reload that the resulting insns need
> to be recognizable (after reload) if they were before. But that is even
> harder to check a priori :-/ And it doesn't help you if the new insn form
> doesn't have the same number of operands or constraint content (as without
> rerecognition the insn code will still be the old one and hence reload
> would look at constraint and operand places of the old insn form). Tough.
I don't pretend to know much about all of this, but rather than not
calling recog() while reload_in_progress, can't we just skip the
gcc_assert() while reload_in_progress?
Peter