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, 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.


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