4 ms·
Telling apart which dead code the programmer thought was meaningful and what is the result of a macro or inlined function is difficult. Using functions and macr
by AgentME 12y ago
Telling apart which dead code the programmer thought was meaningful and what is the result of a macro or inlined function is difficult. Using functions and macros very often causes dead branches to be added, and optimizing out dead branches is a huge performance win. The fact that some already-incorrect code incorrectly behaves after these optimizations are applied is not a good reason to stop doing an entire class of standards-compatible optimizations.
- TheLoneWolfling 12y agoWhat about by default throwing an error or warning only in cases where it is "obvious"? (i.e. only in cases where the check was explicitly stated, so no macros / function boundaries / etc) Ditto, if you have an explicit block (i.e. no macros / etc) that always causes undefined behavior, warn or throw an error by default.
- barrkel 12y agoThere's deducing the range of a variable due to constant expression evaluation and control flow, and then there's deducing its range because of undefined behaviour. I believe this analysis is possible; taint the control flow analysis with a flag. Macro expansion and inlined functions are also not intractable; debug information requires tracking token location information all the way through to generated code, so this information can be used to apply a heuristic. Dead branches don't need to cost that much, BTW. Put the code for disfavoured basic blocks out of line with other code (so it doesn't burn up code cache), and use hinted conditional jumps to enter them (e.g. on x86, forward conditional jumps are predicted not to be taken).
- AgentME 12y agoThat's assuming that apparently dead branches being removed from macros and inlined functions will not cause issues with incorrect code relying on undefined behavior.