In debug builds non-trivial amount of time is spent in InstCombine processing @llvm.dbg.* calls in visitCallInst(). They can be safely ignored.
Added visitDbgInfoIntrinsic() to InstCombiner to intercept and skip them.
Details
Diff Detail
Event Timeline
Adding reviewers + llvm-commits.
This patch seems incomplete. Please upload the correct version.
That's the patch, 1 line. This added visitor function will intercept @llvm.declare and @llvm.value calls and ignore them.
I looked into adding a test case. There is no visible trace of processing these nodes other than -debug output, which in instcombine case dump all nodes before they are being processed. So there's still a trace like "Visiting call @llvm.dbg.value" eve though the visitor routine ignores it.
We can skip debug intrinsics from adding them to the InstCombine worklist.
With this change I can create a test case. And it shaves a few more seconds off compile time.
include/llvm/Transforms/InstCombine/InstCombineWorklist.h | ||
---|---|---|
64 ↗ | (On Diff #95831) | Should you skip it when the List being passed in here is being populated? |
See comment. Also now I think you can probably write a test to make sure the instruction is never inserted in the worklist.
include/llvm/Transforms/InstCombine/InstCombineWorklist.h | ||
---|---|---|
64 ↗ | (On Diff #95831) | I'd hoist the insertion in the working list in a separate helper so that we don't have to copy the check in multiple places. |
lib/Transforms/InstCombine/InstructionCombining.cpp | ||
---|---|---|
3055–3059 | Please expand this comment to explain why we want to skip them. |
lib/Transforms/InstCombine/InstructionCombining.cpp | ||
---|---|---|
3055–3059 | I'm really sorry to keep asking this to be moved, but is there any reason to run any of the code above here for debug intrinsics? |
include/llvm/Transforms/InstCombine/InstCombineWorklist.h | ||
---|---|---|
64 ↗ | (On Diff #95831) | Passing in the initial list from AddReachableCodeToWorklist() without @llvm.dbg works too. I'll make the change. |
lib/Transforms/InstCombine/InstructionCombining.cpp | ||
3055–3059 | // Skip processing debug intrinsics in InstCombine. Processing these call instructions // consumes non-trivial amount of time and provides no value for the optimization. Is this OK? | |
3055–3059 | I'm not sure how far up I can move the check. Top of the for loop? But won't we potentially miss DCE and constant folds above? |
lib/Transforms/InstCombine/InstructionCombining.cpp | ||
---|---|---|
3055–3059 | Any thoughts on this? |
I don't think I saw any more feedback after my last comment. Can someone please reply? Is this change good to go?
test/Transforms/InstCombine/debuginfo-skip.ll | ||
---|---|---|
3 | What is the input to this second run of FileCheck? It's not being piped anything. |
test/Transforms/InstCombine/debuginfo-skip.ll | ||
---|---|---|
3 | Sorry, forgot to update the test, it's meant to be: |
This is still a quite large testcase and I'm under the impression it can be shrunk a bit.
test/Transforms/InstCombine/debuginfo-skip.ll | ||
---|---|---|
55–59 | For example, I'm pretty sure all these attributes are unneeded. |
test/Transforms/InstCombine/debuginfo-skip.ll | ||
---|---|---|
55–59 | This test case was generated from a small source. I wanted to make sure that both @llvm.dbg.decalre and @llvm.dbg.value are present in the IR. I removed the attributes and shortened some strings. Some debug info can probably be removed, but I didn't want to mess with the consistency of the IR to reduce the size. |
What do you mean with "consistency" of IR?
This test is checking that we skip llvm.dbg.* instructions, and that's the only thing it should test.
Your test still contains a large amount of unneeded stuffs, which makes it very hard to maintain and to look for somebody else in the future.
Among others, lifetime.start/end are largely unneeded.
If there's a good reason to keep all this boilerplate around, please elaborate.
The test could probably be further reduced, but I think it's fine now.
The change looked good to me a while ago, and still looks good.
Please wait and check if Craig is happy with this.
Please expand this comment to explain why we want to skip them.