[clang] [Clang] Implement P2809: Trivial infinite loops are not Undefined Behavior (PR #90066)

[Eli Friedman via cfe-commits]

================
@@ -908,6 +908,73 @@ void CodeGenFunction::EmitIfStmt(const IfStmt &S) {
     incrementProfileCounter(&S);
 }
 
+bool CodeGenFunction::checkIfLoopMustProgress(const Expr *ControllingExpression,
+                                              bool IsTrivialCXXLoop) {
+  if (CGM.getCodeGenOpts().getFiniteLoops() ==
+      CodeGenOptions::FiniteLoopsKind::Always)
+    return true;
+  if (CGM.getCodeGenOpts().getFiniteLoops() ==
+      CodeGenOptions::FiniteLoopsKind::Never)
+    return false;
+
+  // Now apply rules for plain C (see  6.8.5.6 in C11).
+  // Loops with constant conditions do not have to make progress in any C
+  // version.
+  // As an extension, we consisider loops whose constant expression
+  // can be constant-folded.
+  Expr::EvalResult Result;
+  bool CondIsConstInt =
+      !ControllingExpression ||
+      (ControllingExpression->EvaluateAsInt(Result, getContext()) &&
+       Result.Val.isInt());
+  bool IsTrue = CondIsConstInt &&
+                (!ControllingExpression || Result.Val.getInt().getBoolValue());
+
+  if (getLangOpts().C99 && CondIsConstInt)
+    return false;
+
+  // Loops with non-constant conditions must make progress in C11 and later.
+  if (getLangOpts().C11)
+    return true;
+
+  // [C++26][intro.progress] (DR)
+  // The implementation may assume that any thread will eventually do one of the
+  // following:
+  // [...]
+  // - continue execution of a trivial infinite loop ([stmt.iter.general]).
+  if (getLangOpts().CPlusPlus11) {
+    if (IsTrivialCXXLoop && IsTrue) {
+      CurFn->removeFnAttr(llvm::Attribute::MustProgress);
----------------
efriedma-quic wrote:

The mustprogress function attribute it affects not only loops, but also loop-like constructs (goto/musttail/etc.).  And that effect infects the whole program: if a program's main() function is mustprogress, the rest of the program is implicitly mustprogress.

I think it's reasonable to turn off the function attribute everywhere, and just mark loops.  That's a bit more conservative than the C++ standard rules (which also allow treating non-loop constructs as mustprogress), but in practice most of the benefit we get from mustprogress comes from marking loops.  And it makes the emitted IR more similar between C and C++, so optimizations will impact both more consistently.

https://github.com/llvm/llvm-project/pull/90066