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: Michael Matz <matz at suse dot de>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: Andrew Pinski <pinskia at gmail dot com>, Peter Bergner <bergner at vnet dot ibm dot com>, David Edelsohn <dje at watson dot ibm dot com>, Ulrich Weigand <ulrich dot weigand at de dot ibm dot com>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 13 Dec 2006 19:21:37 +0100 (CET)
- 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>
Hi,
On Wed, 13 Dec 2006, Ulrich Weigand wrote:
> While we could add reload_in_progress workarounds to all these, it does
> look a bit unfortunate. I hadn't thought so many platforms use these
> types of checks in predicates ...
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.
Ciao,
Michael.