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] |
On 09/03/09 12:46, Vladimir Makarov wrote:Ok, I'll work on an alternative solution. Although it will take more time (a few days I think).Well, I think we should be doing more research when removing patches... It's not like that code isn't traceable.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.
2009-09-03 Vladimir Makarov <vmakarov@redhat.com>
PR bootstrap/41241 * ira.c (update_equiv_reg): Remove check on class likely spill.
k to commit it into the trunk? Jeff, sorry. I committed the patch before reading this.
I don't really like that way of approaching problems.
I think we should try it and see what happens.
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.
I'd rather see us put in a beefier solution prior to getting some nasty-to-debug code generation problem.
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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |