DSrcl

  more sensical approach to analysing this program, e.g. as employed by a human, would be to see that NeverCalled() is the only function that can write Do

It is not only non-trivial but also impossible (even) for a human to see if NeverCalled is ever called. Since NeverCalled is visible to other translation units, it can be called, for instance, by a global constructor before main is called.

Adapting thinkings such as

  "I can't figure out how to optimise this, so I'll do the simplest thing that works."

will disable the compiler from many non-trivial optimizations. Consider eliminating a branch predicated on `w < w + c`: this expression can be, a check for signed-integer-overflow, coming from a macro-expansion and expected by the programmer to be eliminated, a result of constant-progagation, or a result of other optimizations.

Saying you have ideas but don't have time to make a better compiler only makes you an armchair compiler-writer.

The function pointer is static. But the function that mutates it, NeverCalled, is not. One can still indirectly change that function pointer.

  This is probably why there is not a proof yet, since the truth is undesirable.

You are presenting an explanation to a false observation.

Compile with -fno-frame-pointer and you won't see those code. It's for debugger.

A lot of dota's mechanics is designed with the assumption that the player is human -- e.g. skills that can be programmed to be released perfectly but are hard for a human (even pro) to do so reliably (Shadow Fiend's raze is one of them).

Except WebAsm is language independent and reuses DOM (indirectly through javascript).

Labelling an operation -- number of steps of which upper-bounded by 6 -- "effectively constant" is different from considering any real world algorithm with bounded input size.

Calling Scala's immutable vector ops "effectively constant" is not a stretch/hack by any means, considering we also say the same for integer addition and multiplication.

It blocks other interprocedural optimization such inlining and interprocedural const prop.

It's unsafe for a compiler to do this in general (i.e. without annotations) because it can't determine dependencies that are external to the program -- e.g. `one=get(); two=get()`. The dependency between one and two is not obvious to a compiler when IO is involved, so it has to assume the two `gets' has to be executed sequentially.

Register allocation in general is np-complete[1][2]. Having polynomial-time coloring algorithm for SSA doesn't make the allocation optimal -- you still need to "lower" the SSA to proper machine code.

[1] http://www.cs.cmu.edu/afs/cs/academic/class/15745-s07/www/pa... [2] http://pharm.ece.wisc.edu/wddd/2006/papers/wddd_05.pdf