This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix PR middle-end/28690, indexed load/store performance + reload bug


On Mon, 2006-12-11 at 13:06 +0100, Michael Matz wrote:
> On Fri, 8 Dec 2006, Peter Bergner wrote:
> > exactly the same rtl insn (below) passed into eliminate_regs_in_insn as we
> > do with the patched compiler.  The difference is that the unpatched compiler
> > doesn't attempt to call recog on the insn and doesn't have an gcc_assert.
> 
> Hmm, I seem to be confused, but which patch are you refering to now?  I
> don't see any which adds a recog() call.

This is the patch I'm referring to:

    http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00508.html

I didn't add a call to recog(), but by merging the "then" and "else"
code together, the code that normally executed the "else" code
(ie, offset != 0 && plus_src != NULL_RTX) now executes the recog()
that previously existed only in the "then" code.


> > So I'm guessing, we need to just let this insn pass by without trying to
> > call recog() on it?
> 
> If that's the problem, then the predicate (the one rejecting special
> registers) needs testing for reload_in_progress.  Only when that is set
> should we see temporarily invalid instructions with reg 65 in "r" operands
> (although I still find that curious to have at all).

Or maybe we could just gate this call to recog() to the "offset == 0"
case which would mimic the old behavior?

Peter




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]