Just how 'smart' IS the STVD (Cosmic) "Minimize code size (+compact)" optimizer?

[Ted Jackson]

In the attached, notice (in the Disassembly window) how the "Minimize code size (+compact)" compiler option entirely did away with the if-else portion of the code, whereas "No Optimizations" does not do this. Is that telling me that the optimizer is so 'smart' that it could tell I was writing a given byte to data EEPROM, reading it back out from the same location in EEPROM and comparing that to the original value written (to check successful operation) and that it 'assumed' that the two values would necessarily be equal? But if so, isn't it INSANE for the optimizer to make that assumption? And if so, am I limited to fat non-shrunk code that won't fit on my MCU? :\

[Piranha · Accepted solution]

It has nothing to do with those FLASH functions. It just removed the if-else because it does not contain useful code. Apparently NOP is not counted as such and you shouldn't rely on it. Put there a real code and it will not be removed. Also i or q would be volatile, then operations with those also would be preserved.

[Ted Jackson]

Thank you Piranha. That sounds like good advice and I'll keep your suggestions in mind. May I ask what the compiler will consider 'useful' code? For example, if I just add a dummy variable arithmetic computation that isn't used later, it will probably optimize that out too. Is there any guide for dummies like me in anticipating the pitfalls of optimized code and how far one must go in 'outwitting' the optimizer?

If you have the time, here's another head scratcher. If optimized, the comparison is never counted as true and line 13 never executed. If not optimized, it is executed. I included the disassemblies too and the optimized has one less step corresponding to the while() code, though I haven't figured out exactly how it's functionally different. I tried making RxCounter volatile, but no luck.

[Ted Jackson]

This seemed to work: while(RxCounter < 30) { tag[0]=0; } instead of just: while(RxCounter < 30) {}

Shame I can't trust my code if optimizing without a very thorough inspection and re-test. But then, I guess that's the nature of the beast. You can't expect it to reduce the code without introducing some uncertainty in the process.

But code that works when not optimized and suddenly doesn't work (or works wrong) when optimized for space is not good. Maybe the optimizer is just too damn aggressive. Hmm. How many bugs might it have introduced into my code that AREN'T so obvious?