relates to:

• SR-626 No diagnostic for unconditional recursion

Issue Description:

Compiling the following code with `-O` can sometimes result in `foo` just returning `undef`, that is, LLVM removes the infinite recursion because there's no side-effects.

public func foo() -> String {
    return foo()
}

The IR is:

; Function Attrs: nounwind
define { i64, i64, i64 } @_TF8infinite3fooFT_SS() #​1 {
entry:
  ret { i64, i64, i64 } undef
}

This is a safety hole: any manipulations of the return value could be working with random data (if the function isn't inlined), or LLVM inlines the function and propagates the undef deeper through the program.

This behavior is somewhat inconsistent across compilers, e.g. it doesn't seem to happen with my local 3.0 compiler (it has the recursive call), but it does with my current development build which is a week or two old, I think.

Notably this transformation is valid in C (more specifically, this sort of recursion is UB), and it may be hard for LLVM to avoid doing this without inhibiting its ability to delete finite side-effect free loops. https://llvm.org/bugs/show_bug.cgi?id=965 is possibly a relevant LLVM bug. Other languages have encountered this problem too, e.g. Rust, which "solved" it by introducing a warning for obvious cases of infinite recursion.

(Certain phrasings of infinite loops are possibly problematic too.)