When inlining mustprogress functions, if the caller or the callee has
the attribute, we drop the function attribute. The loops that have the
llvm.loop.mustprogress metadata keep their metadata. We do not need to
add new loop metadata to inlined functions because the patch in D86841
already adds the relevant loop metadata in all of the necessary places.
Details
- Reviewers
jdoerfert hfinkel - Commits
- rG46a29e9c6e7f: [Inliner] Handle `mustprogress` functions
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Add a test case with multiple loops in the caller and callee please. also nested ones. And one with the callee loop not having the metadata so we see it won't after.
And a test with both caller and callee having the attribute so no metadata is added.
llvm/lib/Transforms/Utils/InlineFunction.cpp | ||
---|---|---|
2316 ↗ | (On Diff #290391) | Don't walk the blocks but the loops. LoopInfo exposes only top-level loops but you can use it as a graph or employ a worklist to get to the nested ones. I usually see the latter. |
Flipped directions, now it gives the callee loops llvm.loop.mustprogress if a mustprogress function is being inlined.
Assuming it's not part of some other patch, this should also add a LangRef entry for the llvm.loop.mustprogress metadata.
I also don't see where this avoids applying the metadata if the caller is mustprogress as well. Seems to work fine in the tests, but I don't understand why looking at the code...
Please split the loop metadata and the inliner stuff. I think the metadata is needed in clang already, it should go in after the functionattr IR patch
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.