[pdw]

How much of this is driven by modern C++ style? I always assumed optimizers needed to become much more aggressive because template-heavy code results in convoluted IR with tons of unreachable code. And UB-based reasoning is the most effective tool to prove unreachability.

[not2b]

None of it: we're talking about C here, and every point in the article applies to the C standard as it existed when Linus posted his message to comp.os.minux so long ago.

[aw1621107]

> template-heavy code results in convoluted IR with tons of unreachable code

Does it? Honest question; my impression was that template-heavy code can tend to produce deep call trees, but not necessarily outright unreachable code unless you count instantiations ruled out by SFINAE/std::enable_if/tag dispatching, for which UB-based analyses are not necessary.

In addition, I thought template (meta)programming relied very heavily on compile-time knowledge, which seems to obviate the need for UB-based analyses in many cases.

I'm not particularly experienced, though, so maybe there's a gaping hole I'm missing.

[ncmncm]

It is quite common for any heavily inlined code to have lots of dead sections. Template code is very frequently heavily inlined. So, it is common for compilers to prune out the dead branches.

But C code is often heavily inlined, too, and similarly pruned.

[aw1621107]

Guess I need to pay more attention to the template code I use. I knew that they tended to rely very heavily on inlining for good performance, but I haven't read as much about the presence/absence of dead code, though to be fair maybe the deadness isn't always obvious to the programmer?

In any case, thanks for correcting me!

[ncmncm]

I should add that most of the Standard library will not often have many visibly dead code branches to prune. Most of what gets discarded is arguments and calls to no-op functions, all the scaffolding. But there is a lot of that. So, for example, an iterator on std::function isn't typically a pointer, but after optimization the instructions left standing are the same as if it was one.

[ncmncm]

Oops: s/std::function/std::vector/