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
Unit Tests
Time | Test | |
---|---|---|
60,030 ms | x64 debian > libFuzzer.libFuzzer::minimize_crash.test |
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