From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joern Rennecke To: crux@pool.informatik.rwth-aachen.de (Bernd Schmidt) Cc: law@cygnus.com, meissner@cygnus.com, toon@moene.indiv.nluug.nl, egcs@cygnus.com Subject: Re: Reload patch to improve 386 code Date: Fri, 04 Sep 1998 22:36:00 -0000 Message-id: <199809050007.BAA17954@phal.cygnus.co.uk> References: X-SW-Source: 1998-09/msg00226.html > Inheritance doesn't seem to cause problems with my patch; I've never touched > it and did not run into bugs. I just think it's horribly complicated and > could be done somewhat cleaner, and more reliable. Just a few days ago I ran > across a piece of code for which reload generated twice as many instructions > as necessary, just because the inheritance code didn't catch a particular > case. The reload_cse_regs code and the inheritance code do some very similar > things, and I think it would be better to have only one piece of code that > handles everything in a general fashion. I have patches to make the inheritance perform better and more consistently. > The only major obstacle I see is that currently the MEMs made by reload for > spill slots in the stack frame don't get handled very well by the alias code. > If alias.c knew that these don't alias with other MEMs, reload_cse_regs would > immediately be much more powerful. reload_cse_regs can't do register re-assignments, and it doesn't see when a sequence of instruction loads a register that it has clobbered first. Actually, it doesn't even begin to understand multi-instruction sequences that load a value. It is really a weaker concept than reload inheritance. The only time when it performs better than a good reload inheritance is when the lifetime of reloads becomes muddled (e.g. when stuff is merged to RELOAD_OTHER, and there are other reloads for the same insn.