2 ms·

On 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 ago
Then 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 ago
  If 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 ago
    At 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 ago
    If 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 ago
      I'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 ago
        That'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.

AstralStorm 8y ago

Then 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 ago
If 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 ago
  At 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 ago
  If 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 ago
    I'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 ago
      That'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.