This fixes Bug https://github.com/llvm/llvm-project/issues/53492
and uses InlineHistory to track recursive inlining.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thanks for looking into this! Have you considered/looked into using the same approach as LLVM? i.e. keeping an inline history to track what's already been inlined?
Thanks for updating! (Sorry, coming back from OOO)
mlir/lib/Transforms/Inliner.cpp | ||
---|---|---|
395–398 | Please move these functions outside of the anonymous namespace. | |
396–400 | This doesn't look scalable, given that it assumes the existence of a "callee" attribute. Can you instead use op.getCallableForCallee()? The result of that is either a SymbolRefAttr (which is easily dumpable), or a Value (which could just fallback to the _unnamed_callee_ you have here). | |
403–404 | Can you reflow these comments? it doesn't look like it wraps at 80. | |
405 | ||
406 | ||
486 | Can we use Optional<int> instead of int here? It would remove the magic -1 handling. |
mlir/lib/Transforms/Inliner.cpp | ||
---|---|---|
372–373 | Do we need to anchor on FlatSymbolRefAttr? We should be able to print any SymbolRefAttr, e.g. using debugString(in mlir/Support/DebugStringHelper.h). | |
382 | Can you use MutableArrayRef here instead? | |
394 | Unrelated? | |
492 | Please cache the end iterator here. | |
540 | You'll likely need a (void)hisStr after this to avoid unused variable warnings. Also, can you extend the name of this to be more explicit on what this is doing? | |
mlir/test/Transforms/bugfix53492_inlining.mlir | ||
3 ↗ | (On Diff #440682) | Can you rename the file (or just merge it into inlining.mlir) and the functions in this file to better represent what this is testing, as opposed to referencing the bug? The fix is for inlining recursive functions, which is descriptive enough that I don't think we need/should reference the bug here. |
mlir/lib/Transforms/Inliner.cpp | ||
---|---|---|
492 | Actually the 'calls.size' changes in this loop. Below it calls inlineCall (in Utils/InliningUtils.cpp) which calls interface.processInlinedBlocks which then calls collectCallOps that adds new inlined calls. Since the calls is reference to inliner.calls it changes. |
mlir/lib/Transforms/Inliner.cpp | ||
---|---|---|
492 | Ignore above. I had misunderstood your comment earlier. |
Do we need to anchor on FlatSymbolRefAttr? We should be able to print any SymbolRefAttr, e.g. using debugString(in mlir/Support/DebugStringHelper.h).