We now limit ADCE to only remove debug intrinsics if it does something else
that would invalidate cached analyses anyway.
As we've seen in
https://github.com/llvm/llvm-project/issues/58285
throwing away cached analysis info when only debug instructions are removed
can lead to different code when debug info is present or not present.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Transforms/Scalar/ADCE.cpp | ||
---|---|---|
576–577 |
LGTM - I think not deleting debug intrinsics if there would be no other codegen changes is the right call for now as a simplest viable fix for the linked issue; hopefully this doesn't result in intrinsic bloat, but if it does that can be solved separately.
This caused a large compile-time regressions in some cases: http://llvm-compile-time-tracker.com/compare.php?from=57833636816a13ccda53714413c532dc81e3b5ff&to=8aa9ab336889ae2eb8e4188036faeb151379ab7b&stat=instructions:u In particular tramp3d-v4 with debuginfo regressed by 15%.
So I think this is probably not the right way to fix this issue. I think what we can do instead is to mark MemorySSA as preserved if only debuginfo intrinsics have been removed. (This is safe, MSSA explicitly never tracks debuginfo intrinsics.)
Should I revert this for now then or do we leave it in-tree while determining what we do about it?
Does everyone agree this is the way forward then? If so I can put up a patch doing that on Monday.
Probably worth picking up the discussion on the original bug. I think @aeubanks had speculated about this other path - it does seem more brittle (playing whack-a-mole with preserving analyses - can we say it preserves all analyses despite removing debug intrinsics? And then whack-a-mole in the opposite direction to flag certain analyses as unpreserved if they do get broken by the intrinsic removals?)/might have some other concerns.
can move this into an else of the previous if statement