From: Spiro Trikaliotis (trik-news_at_gmx.de)
Date: 2003-12-09 19:10:19
Hi Uz, On Tue, Dec 09, 2003 at 06:42:56PM +0100, Ullrich von Bassewitz wrote: > Is an optimizer that has to look forward an unknown number of instructions > still a peep hole optimizer? It may be possible to ignore this problem, hoping > that the compiler doesn't generate this sort of code. But if a lot of the > optimizer code is built on this assumption, what if parts of the code > generator are changed later? And what about inline assembly? Ok, I have not though about inline assembly. Anyway, from remembering your previous posts, I had the impression that cc65 does *not* heavily reuse registers, so I assumed that something like this is not possible. Obviously, you know the code much better than me, and I have to admit that my only try to write and maintain a compiler has been many years before and it never come to the state to be usable, so I cannot tell about implied complexities to this. And: No, I don't think ignoring such a problem is good practice! From your statement, I assume that cc65 optimizes on the assembly code itself, not on any type of intermediate code? From my rememberings of compiler writing, a coverage analysis (which was told as being always done) tells me when a value is surely not needed anymore, and such an analysis would be done even for register contents in the optimization state (well, I must admit that I think this was told in university, but I'm not sure 100%). This information would be sufficient, but from your statement, I assume this information is not available, is it? > > Is this sequence only occurring while using shifts, or are there other > > circumstances that may lead to these? > > As far as I can say it is only occuring for right shifts by 8 bits, and in > addition to that, the left operand must be a global variable. The pattern for > locals looks different as well as the pattern for anything else as the left > operand. Well, this surely is an argument not to put to much effort for optimizing this very rare case. As I told above, ignoring possible problems is not a solution, and I'm sure anyone ever hit by a compiler error due to optimization and having to debug much code until he looks at the generated output, will have the same opinion. Later, Spiro. -- Spiro R. Trikaliotis http://www.trikaliotis.net/ ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo_at_musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2003-12-09 19:11:08 CET