Re: RFA: patch to solve PR41241

[Vladimir Makarov <vmakarov at redhat dot com>]

Jeff Law wrote:
> On 09/03/09 12:46, Vladimir Makarov wrote:
> > > > 2009-09-03  Vladimir Makarov <vmakarov@redhat.com>
> > > >
> > > >    PR bootstrap/41241
> > > >    * ira.c (update_equiv_reg): Remove check on class likely spill.
> > > I'm not sure this is safe -- the mn102 change was merely 
> > > generalizing some existing code.  Prior to the mn102 change we 
> > > rejected rejected pseudos which preferred a register class with a 
> > > single register.    The mn102 change merely extended that to 
> > > rejecting pseudos which preferred a class that was likely spilled.
> > k to commit it into the trunk?
> > Jeff, sorry.  I committed the patch before reading this.
> Well, I think we should be doing more research when removing 
> patches...  It's not like that code isn't traceable.
>
> > I think we should try it and see what happens.
> I don't really like that way of approaching problems.
>
>
> >   I guess that most probably the removed condition was false when we 
> > checked uninitialized data.
> True.  But we could easily be introducing difficult to detect code 
> generation regressions on a variety of platforms -- basically any 
> where we have singleton register classes.
>
> >   So I think it is pretty safe at least for major platforms.  In any 
> > case, I think it is a wrong place to fix it.  It was also very 
> > aproximate solution.  Actually the comment stated this.
> A number of our major platforms have singleton classes -- so I don't 
> think it's necessarily that safe.  I would agree that isn't not the 
> best place to fix this -- Jim and I discussed it eons ago.  The 
> problem, IIRC, was that fixing it in reload was going to be 
> exceedingly tough and we'd been dealing with it on other platforms by 
> rejecting certain equivalences -- all that was different on the mn102 
> is that we have some classes that we marked as likely to be spilled 
> even though they had more than one register in the class.
>
> > If the patch breaks some port and we decide that it can not be fixed 
> > in reload and should be fixed in a manner as before,  I could 
> > implement checking all constraints in insn to more accurately avoid 
> > the situation than it was before.
> I'd rather see us put in a beefier solution prior to getting some 
> nasty-to-debug code generation problem.
Ok, I'll work on an alternative solution.  Although it will take more 
time (a few days I think).