This is the mail archive of the 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: PR middle-end/30191 (was: [PATCH] Fix PR middle-end/28690, indexed load/store performance + reload bug)

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?


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