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

[Robin Kruppe via Phabricator via llvm-commits]

rkruppe added a subscriber: rnk.
rkruppe added a comment.

Clearly the current semantics of LLVM IR have a forward progress guarantee and I agree that should be documented.

The question of how things //should be// is harder, and I don't know if there really is any community consensus about it. But while the topic is alive again, I want to take the opportunity to point out that we have other options than just not doing the optimizations or baking forward progress into LLVM IR. The more invasive proposal discussed alongside `llvm.sideeffect` <https://lists.llvm.org/pipermail/llvm-dev/2017-October/118558.html> was:

- define LLVM IR to not have a forward progress guarantee as baseline, but add a function attribute to add it back in
- let frontends for languages with forward progress guarantee use this attribute to opt into the optimizations in question
- 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)

Other than side-stepping most concerns about the optimization impact of the intrinsic, this also avoids overly privileging C's particulars in the IR to the (potential) demerit of every other language. As @rnk said in the comment that originally proposed this:

> The forward progress required by C++ is the odd duck here. We should ask frontends to put a function attribute on functions that they want to receive this kind of optimization. <https://bugs.llvm.org/show_bug.cgi?id=965#c25>


Repository:
  rL LLVM

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

https://reviews.llvm.org/D65718