1

I am wondering if any C++ compilers (optimizers) guarantee that a code that is highly "decorated" with some meaningless operations (e.g. if (true) or do-while(false) pattern) will be generated (when compiling with all the optimizations for speed) into exactly the same executable that would be, if the source code didn't contain these "decorations".

I hope my question is clear - if not I will try to rephrase it is some way - anyway here is, why I am asking it, to make it more clear: I have a 'legacy' piece of c++ code that uses macros quite heavily. Some of them are expressions, so it might be good to wrap them into do-while(false), although these macros themselves contains instructions like "break" or "continue", so I came even further to "if(true)[MacroBody]else-do{}while(false)". So far, so good, maybe not very clean but all should be fine, however I noticed that my executable (MSVC, all optimizations for speed) grows by 2kB after such "decorating".

(My feeling is that the compiler, after making some initial optimizations, was glad enough by what it did so far and stopped making further optimizations. The bad thing is that I was unable to minimize the case - the difference in executable replicated only on real-life case. That's why I would like to ask, if any of you, more specialized in compiler construction, have some knowledge about it. If my perception was right, currently it might work a bit heuristically - like compiler coming to a conclusion: "Looks like I did quite many optimizations, it may be just enough")

moremover
  • 61
  • 1
  • 5
  • 1
    No, optimisers generally guarantee nothing. Compare the assembly. Did it change? – eerorika Feb 04 '22 at 11:04
  • Some construct might make optimizer miss some patterns, but I don't expect any branches for `if (true)` or `do .. while (false);`. – Jarod42 Feb 04 '22 at 11:06
  • @eerorika : Yes, just as I wrote, the code changed - the produced executable grew by 2kB after meaningless decorations with do-while-false-like pattern (release mode with all optimizations for speed; MSVC). The change was in some inlined functions (quite a big "stack" of inlined functions), so it was really difficult to analyse in disassembly. After I reverted the decoration (removed do-while-false-like pattern), I got the same executable as before. – moremover Feb 04 '22 at 11:16
  • @moremover The size of executable changing doesn't necessarily mean that the program code has changed. – eerorika Feb 04 '22 at 11:17
  • 2
    eerorika is right as far as guarantees go but it’s *very* unlikely that such useless constructs would remain in compiled code — modern compilers are *very* good at recognising such dead code, and stripping it out. This is particularly true since, as you’ve noticed, it’s common for macros to require such things. It’s all but certain that the change in executable size is unrelated, if the situation is indeed as you have described it. – Konrad Rudolph Feb 04 '22 at 11:17
  • is there any reason you use `do{}while(false)` or `if(true){}` instead of simply `{}`? – apple apple Feb 04 '22 at 13:06
  • What did you compare of size? The generated executable file or the content of the executable. That is quite different as the file may contain different amount of debug output. I can't believe that any of today's compilers will not throw away if(false) and such things. – Klaus Feb 04 '22 at 14:31
  • @appleapple [Indeed there is](https://stackoverflow.com/a/154138/1968). Incidentally, **you must not use `if (true){…}`**, it doesn’t work, because it changes how a dangling-`else` will be interpreted. Only `do {…} while (false)` works here. – Konrad Rudolph Feb 04 '22 at 15:04
  • @Konrad Rudolph : Yes, if(true){} itself is useless. I came to a resolution to give a try to a larger construct **if(true) { MACRO_BODY_HERE } else do {} while(false)** because I had instructions like break and continue within macros, so their behaviour was broken with a simple do{...}while(false). And with this larger construct I faced the surprise with the larger executable... – moremover Feb 04 '22 at 15:55
  • @KonradRudolph thanks, learned something new (I initially think OP means add that in caller of macro) – apple apple Feb 04 '22 at 18:19

0 Answers0