Common Code Elimination
cortex-m3 uVision 5.13
I recent had to up the optimization level on my project to level 2 because my code size was too large for my target memory. In doing this I found that it seems to be doing common code elimination where valid routines are not being compiled/linked into the image.
This has caused some routines to be practically wiped out because another is very similar but has some differences. I guess they were common enough for the compiler to decide to get rid of one of them.
I have been Googling and searching everywhere for a way to turn off just the common code elimination but cannot find anything that I can use with uVision.
There is a C51 pragma to change the optimization level to stop this on a file by file basis but the uVision compile causes a error.
There must be a way to turn this off. I understand it is trying to save me space but it is also changing or in some cases eliminating functionality.
Does anyone know of a pragma that will work or something I can do?
Thanks
P.S. of course this happens 2 days before a major delivery on a weekend!!
So I'll ask my question again, is there a pragma or switch that I can use to prevent common block optimization?
Your request to the manual lookup service has found this:
www.keil.com/.../armcc_chr1359124215328.htm - NOTHING APPROPRIATE FOUND
www.keil.com/.../armcc_chr1359124194749.htm - NOTHING APPROPRIATE FOUND
If you think really found a problem, I suggest you attempt to be a tad more precise when passing information to support.
Around the specific routines you do not want optimized
#pragma push // save current pragma state #pragma O0 Your routine that you do not want optimized #pragma pop // restore previous optimization level
It does seem reasonable for the compiler to optimize out redundant code if only the strings are different (even seems like it SHOULD do this at higher optimization levels). It is easy to pass in different strings to the same code. It does seem like the issue may be larger than this but I don't believe the proper fix (on Keil's part) would be to not optimize out the code, but to just make sure the proper strings are used in each case. As people have said it is the functionality that needs to be the same, not the exact code generated.
Also is next to impossible to debug the source code at Optimization level 2 and above (level 1 is not horrible, save switch statements). I find that there is often no way to set break points based on the high level code. Going into the disassembly and setting break points and stepping through at that level can be very helpful. I am not sure if this is the case, but my bet is that when you say that "nothing happens" in the code, if you actually step through the disassembly you will find there is a lot more than nothing going on.