Updated to include syntax modifications in the llvm/utils

Fixed broken tests, think the changes make sense.

Fixed broken test.

Added a specific basic-aa maxobjsize test.

Updated commit message.

Inliner changes now that the clang implementation in D86841 has changed. Can I remove the inliner nested loops and multiple loops tests now? They're not as relevant anymore.

Fixing buildkite build.

Rebasing.

buildkite fix.

Fixes.

Removed extra file.

NFC fixes.

changed stats trackers

Rebase

Fixes.

In D85393#2299787, @Meinersbur wrote:

Should there be some documentation about the new attribute?

fixes.

more fixes.

attempt 3

attempt 2, ignore

addressed nit.

rebase.

rebase

rebase to hopefully fix buildbot

Fixes.

All language standards (minus gnu extensions) are now tested.

Split them into pre and post forward progress requirement tests, now the difference is much easier to catch.

Fixes.

Rebase.

Clang-tidy fix.

Rebase to fix buildkite failure.

Defaults were wrong (0), switched default maxobjsize assumption (~uint64_t(0)).

Formatting changes.

Added LangRef definition, added missing test and corresponding logic.

Small renames.

Updated definition of hasMustProgress to also include willreturn as per the LangRef definition.

Removed unofficial link, I agree that an unofficial link isn't that much better than no link. Updated wording as well.

Addressed inline comments.

Yep I wasn't entirely sure before but I am now.

Updated wrt nit.

Addressed comments, does this sound like an appropriate wording for the behavior wrt callees?

Updated wording.

Ping. Is this good to go?

Decreased bloat in the OpenMP test modifications.

Addresses inline comments (I think), and adds a test.

Sorry, it slipped. Anything else?

Sorry, updated accordingly.

No-op to fix buildbot failure to apply patch.

Tests renamed.

Fixed failing test.

Rebase.

Flipped directions, now it gives the callee loops llvm.loop.mustprogress if a mustprogress function is being inlined.

On second thought, we don't need this for mustprogress. If the callee is` mustprogress`, the caller cannot become mustprogress as well without changing program behavior as a result of inlining.

Renamed.

Added a helper for readibility, and some missed comment updates.

Updated to rely on the new mustprogress attrs.

Flipped direction.

Change direction.

Flipped directions and a rename.

More tightly follows both the C and C++ standards. maynotprogress is only added to C functions when compiled with C11 or later.

Updated the description based on conversations on the mailing lists.

Added tests and changed the loop iteration method.

Rebase.

Renames.

Renamed mayprogress to maynotprogress.

Renamed to maynotprogress.

Renamed to maynotprogress.

Address comments.

Cleaned up tests, and made the changes necessary for changing the attribute names.

In Summary:

• I changed the llvm loop metadata name to mustprogress, to indicate that loops with this attribute are required to have side-effects.
• The mayprogress function attribute is applied to functions where an infinite loop is found with a constant conditional.
• The mustprogress attribute is applied to loops within a mayprogress function that do not have a constant conditional.

Changing name of function IR attribute from noprogress to mayprogress to make the semantics clearer in that if this attribute is applied to a function, it is now permitted to not make forward progress, but may still make forward progress as opposed to never making any forward progress which is what noprogress sounds like.