I grilled an LLM for a bit to see if it could justify the old forward progress rule. The only thing I got that passed the smell test was that it’s useful for the optimizer to be able to optimize:

    messy_pure_computation();
    some_atomic.store(1, relaxed);
by moving the store before the computation. (Stronger stores would require additional analysis.)

I admit I’m unconvinced that this is particularly useful.

(I got many other ideas that did not pass my personal smell test.)

You will find the answer you seek not from an LLM, but from the talk Forward Progress Guarantees in C++ by Olivier Giroux at CppNow 2023. It's a long talk, with lots of details about forward progress, but I've set the timestamp[1] to the infinite loop bit.

[1]: https://youtu.be/g9Rgu6YEuqY?si=_l9JwKhjvIdFEDEX&t=3819

I thought it was generally so the compiler can merge two computation loops without proving if one of them runs forever .

Correct. See N1528: "Why undefined behavior for infinite loops?" https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1528.htm