- User Since
- Feb 12 2020, 7:33 AM (33 w, 7 h)
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.
Removed extra file.
changed stats trackers
Mon, Sep 28
attempt 2, ignore
Sun, Sep 27
rebase to hopefully fix buildbot
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.
Fri, Sep 25
Rebase to fix buildkite failure.
Defaults were wrong (0), switched default maxobjsize assumption (~uint64_t(0)).
Added LangRef definition, added missing test and corresponding logic.
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?
Wed, Sep 23
Ping. Is this good to go?
Tue, Sep 22
Decreased bloat in the OpenMP test modifications.
Addresses inline comments (I think), and adds a test.
Mon, Sep 21
Sorry, it slipped. Anything else?
Sat, Sep 19
Sorry, updated accordingly.
Mon, Sep 14
No-op to fix buildbot failure to apply patch.
Fixed failing test.
Sun, Sep 13
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.
Added a helper for readibility, and some missed comment updates.
Updated to rely on the new mustprogress attrs.
Fri, Sep 11
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.
Tue, Sep 8
Updated the description based on conversations on the mailing lists.
Added tests and changed the loop iteration method.
Mon, Sep 7
Fri, Sep 4
Renamed mayprogress to maynotprogress.
Renamed to maynotprogress.
Renamed to maynotprogress.
Thu, Sep 3
Cleaned up tests, and made the changes necessary for changing the attribute names.
- 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.