3 ms·
For example, I'll boldly state that optimizing out a "if (p == NULL)" only because p was dereferenced earlier never makes sense. Code containing such a check is
by caf 8y ago
For example, I'll boldly state that optimizing out a "if (p == NULL)" only because p was dereferenced earlier never makes sense. Code containing such a check is never performance sensitive enough to justify the tradeoff (or it's really bad code).
This kind of thing really comes to the fore when the compiler is doing a lot of inlining. Say you have some kind of utility function:
int frob(struct foo *f)
{
int r;
if (f != NULL)
{
/* things */
}
else
{
/* other things */
}
/* more things */
return r;
}
..and you call this function all over the place. If some of those callsites end up with `frob()` being inlined, and the compiler can see that the pointer passed is never NULL at that particular site, it can usefully eliminate the dead code. This despite the fact that the code isn't dead in general - just at some of the callers.
- jstimpfle 8y agoOn the other hand, if the chunk is significant enough to reward removal, the function probably shouldn't be inlined in the first place...
- AstralStorm 8y agoThen maybe it should, cause you're using only happy hot path and not the NULL one. Removing even one branch and debloating cache in a hot path can be significant. And then DCE will enable further optimizations. If you want to ensure something is not inlined, you're free to do so.
- jstimpfle 8y agoIf it were really that performance critical the programmer would not call a swiss army knife utility function that contains a lot of unneeded code (replace "would" by "should" if you like). If compiler optimization gets to be more and more about making poorly structured code barely faster, no wonder we have all these discussions about uncalled-for optimizations.
- AstralStorm 8y agoAt some point you hope the compiler is able to remove dead branches and function stack setup or you end up with massive code duplication...
- caf 8y agoIf the alternative is the coder having to write a separate "frob_notnull()" function, to be used specifically in certain fastpaths, then yes - that is exactly what many people want from compiler optimisation.
- caf 8y agoI'd also point out that this is a strange optimisation to choose to pick on, because the only time it's potentially problematic is when a NULL pointer dereference doesn't necessarily trap, which certainly not the usual case on the platforms where common compilers enable it by default (and for the unusual cases, like kernels, the compiler option to disable it is there).
- jstimpfle 8y agoThat's true - see my other comment below the original one. I'd remembered that one from faint memory as one of the canonical examples of optimizations gone wrong. And think it might have been a case where that access comes AFTER a test. I don't really remember, though - and I've never had serious problems with optimizations myself.
- deleted 8y ago[deleted]
- MaxBarraclough 8y ago> If you want to ensure something is not inlined, you're free to do so. Not really. The compiler is permitted to inline or 'outline' as it sees fit, courtesy of the 'as if' rule. C doesn't let you tell the compiler what code to generate.