This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR middle-end/28690, indexed load/store performance + reload bug
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: dalej at apple dot com (Dale Johannesen)
- Cc: dalej at apple dot com (Dale Johannesen), bergner at vnet dot ibm dot com (Peter Bergner), gcc-patches at gcc dot gnu dot org, matz at suse dot de (Michael Matz), ulrich dot weigand at de dot ibm dot com (Ulrich Weigand), pinskia at gmail dot com (Andrew Pinski), dje at watson dot ibm dot com (David Edelsohn)
- Date: Tue, 12 Dec 2006 12:40:30 +0100 (CET)
- Subject: Re: [PATCH] Fix PR middle-end/28690, indexed load/store performance + reload bug
Dale Johannesen wrote:
> On Dec 11, 2006, at 12:46 PM, David Edelsohn wrote:
>
> > Hmm. There don't appear to be many options. This is just how
> > GCC's current register allocator works. Another intermediate register
> > class probably would encounter the same problem.
> >
> > This patch is okay, but please update the comment above the
> > predicate explaining why accepting anything for reload_in_progress is
> > necessary.
> >
> > Thanks, David
>
> I'm doubtful a target-specific fix is the right idea. Don't other
> targets have the same problem?
Well, the problem itself is target-specific, because the predicate
gpc_register_operand that accepts only certain registers is target-
specific.
I guess one question is, why do you need that predicate in the first
place, and don't just use register_operand? In particular, given the
issues discussed in this thread, the predicate doesn't appear to have
the intended effect anyway ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com