Non-termination *is a side effect*. A function which does not terminate is not pure in any reasonable sense of the word.
Conversation
No language needs to cater to optimization of functions which don't obviously terminate. Writing such functions is a bug - either a behavioral bug (if it turns out really not to terminate) or an analyzability bug (correctness is non-obvious).
1
Turning non-termination into memory corruption and other awfulness isn't something that safe languages can accept. It doesn't matter that it's already a bug. It has to remain safe, and has an impact on language semantics. The sideeffect attribute has a huge performance cost.
2
That's not the consequence of what I said. Rather, unless the safe language has a proof of termination, it marks the function non-pure.
1
If this produces notably worse optimization, it's the fault of the person who wrote the code that doesn't obviously terminate, not the compiler's fault.
1
I say this as someone who's been guilty (in musl) of lots of code with non-obvious logic for termination or satisfying of some other critical invariant, and I want to fix it. Penalizing it with bad performance is a feature. :-)
1
Compilers are extremely bad at proving termination and the issue with the sideeffect intrinsic is it acts as a universal side effect and is not handled by optimizations. It is treated as potentially doing global memory writes, etc. and completely breaks all other optimizations.
1
So for example, you can have a simple loop over an array based on the length, and the compiler may not be able to tell that terminates since it can't tell that the length of the array isn't changed (even though a human trivially can). If you insert the intrinsic it destroys perf.
2
The compiler can no longer really optimize the loop. It has a universal side effect in each iteration which could do pretty much anything including writing to memory. It's a terrible 'solution' to present for a self-inflicted problem that's easy and straightforward to solve.
1
You would need to insert that intrinsic into most function calls and loops, destroying performance. Simply disabling removal of functions that may never terminate will BARELY impact performance and would be straightforward but they haven't done it instead proposing an awful hack.
1
It would seriously impact compilation time and performance, to work around a buggy optimization that's still wrong with that intrinsic present. It doesn't matter if non-termination is usually a bug. That doesn't mean languages can permit memory corruption, etc. if that happens.
You can't permit that in C either in the general case, even with how the standard was defined, since they only made infinite loops able to terminate if they have a non-constant condition (my Clang example has a constant expression: 1) and the loop has no side effect.
1
The solution is very simple for LLVM: do not remove function calls if removing the function call can impact semantics. Non-termination is a side effect. If they want that optimization, they have to check if the function is known to always return, which they can very easily do.