[PATCH] D65718: [LangRef] Document forward-progress requirement

[Ralf via Phabricator via llvm-commits]

RalfJung added a comment.

> Does this need a side effect? Per the current definition, no. Per C++, yes.

What does "need a side-effect" mean here? Do you mean whether `llvm.sideffect` has to be added to avoid UB?
Per my reading of C++, an atomic fence is considered a side-effect for the purpose of forward progress (looks like an atomic operation to me, even if it is relaxed), so this loop is //not// UB and may //not// be optimized away.

> use a combination of that attribute and llvm.sideeffect where more fine-grained control is needed (such as C, where forward progress is the default but some loops are exempt)

AFAIK, in C forward progress is the default //for loops// (except, as you said, if their condition is a constant). But I cannot see anything in the C standard that allows a forward progress assumption for recursion or `goto` or any other form of infinite execution (if they exist).

> The question of how things should be is harder

Is it worth saying in the docs that this is subject to discussion, or so?
Basically I hope we can use this patch as the //start// of a discussion, not as a way of cementing the current semantics (which are a bad fit for every language except for C++).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65718/new/

https://reviews.llvm.org/D65718