This is an archive of the discontinued LLVM Phabricator instance.

[MemCpyOpt] Remove MemDepAnalysis-based implementation
AbandonedPublic

Authored by nikic on May 8 2021, 12:22 PM.

Details

Summary

The MemorySSA-based implementation has been enabled for a few months (since D94376) without any issues that I'm aware of. This patch drops the old MDA-based implementation entirely.

I've kept this to only the basic cleanup of dropping various conditions -- the code could be further cleaned up now that there is only one implementation.

Diff Detail

Event Timeline

nikic created this revision.May 8 2021, 12:22 PM
nikic requested review of this revision.May 8 2021, 12:22 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 8 2021, 12:23 PM
nikic updated this revision to Diff 343861.May 8 2021, 1:05 PM

Fix clang-format warnings.

asbirlea accepted this revision.May 17 2021, 12:47 PM

Thank you for cleaning this up!

This revision is now accepted and ready to land.May 17 2021, 12:47 PM

Did we change the default after the 12.0 branch? If so, it might be helpful to keep it until we branch for 13.0, so if users on 13.0 run into issue they can still fall back to the old version in the next release?

nikic added a comment.May 18 2021, 1:51 PM

Did we change the default after the 12.0 branch? If so, it might be helpful to keep it until we branch for 13.0, so if users on 13.0 run into issue they can still fall back to the old version in the next release?

I don't think this is a useful consideration. If there are issues, they need to be fixed on the release branch for everyone, not worked around by flipping a flag.

fhahn added a comment.May 18 2021, 2:45 PM

Did we change the default after the 12.0 branch? If so, it might be helpful to keep it until we branch for 13.0, so if users on 13.0 run into issue they can still fall back to the old version in the next release?

I don't think this is a useful consideration. If there are issues, they need to be fixed on the release branch for everyone, not worked around by flipping a flag.

I agree, but sometimes that's not an option in practice, e.g. if the issue only pops up after the release. (also some vendors may not be able to ship point release quickly, so workarounds can be required in practice)
It might be a bit over cautious, but from my experience it is quite common for issues to surface after a release is done. Given that the cost of keeping the code for the ~2 months until the next release branch seems low to me, I'd prefer to err on the side of caution. But I'm not holding that opinion strongly, so if removing the code now instead of in 2 month makes things noticeably easier that's fine by me.

I believe the process is to additionally test a release after it's been cut, and potential issues that arise can be fixed and cherry-picked into that release. Flipping back the flag would probably not be a useful fix after 6+month, rather resolving the bug would be.
As an additional data point, we've had several internal releases since the flag was flipped and haven't encountered any issues. I'm not saying bugs are sure not to exist, just that there has been some fairly thorough testing done and I'd opt to fix forward rather than switch back to the MemDepAnalysis implementation.
If you have strong reasons to hold back another couple of month on this cleanup, that's an option too, I'm just outlining my reasoning for moving forward.

fhahn added a comment.May 19 2021, 2:32 AM

I believe the process is to additionally test a release after it's been cut, and potential issues that arise can be fixed and cherry-picked into that release. Flipping back the flag would probably not be a useful fix after 6+month, rather resolving the bug would be.
As an additional data point, we've had several internal releases since the flag was flipped and haven't encountered any issues. I'm not saying bugs are sure not to exist, just that there has been some fairly thorough testing done and I'd opt to fix forward rather than switch back to the MemDepAnalysis implementation.
If you have strong reasons to hold back another couple of month on this cleanup, that's an option too, I'm just outlining my reasoning for moving forward.

My motivation to keep the code until the release was not so we can flip back the flag in the codebase; I agree we should just fix the bugs in the new version. I meant the flag may be helpful to end-users who cannot easily update after the release and could use the flag as workaround. It is all what-ifs at this point though :) If it makes planned upcoming work easier, removing the code now sounds good. If it is mostly a matter of removing unused code a bit earlier, I have a slight preference to keep it until the next release branch (I'm happy with the patch moving ahead, I mainly wanted to share another experience to consider)

I believe the process is to additionally test a release after it's been cut, and potential issues that arise can be fixed and cherry-picked into that release. Flipping back the flag would probably not be a useful fix after 6+month, rather resolving the bug would be.
As an additional data point, we've had several internal releases since the flag was flipped and haven't encountered any issues. I'm not saying bugs are sure not to exist, just that there has been some fairly thorough testing done and I'd opt to fix forward rather than switch back to the MemDepAnalysis implementation.
If you have strong reasons to hold back another couple of month on this cleanup, that's an option too, I'm just outlining my reasoning for moving forward.

My motivation to keep the code until the release was not so we can flip back the flag in the codebase; I agree we should just fix the bugs in the new version. I meant the flag may be helpful to end-users who cannot easily update after the release and could use the flag as workaround. It is all what-ifs at this point though :) If it makes planned upcoming work easier, removing the code now sounds good. If it is mostly a matter of removing unused code a bit earlier, I have a slight preference to keep it until the next release branch (I'm happy with the patch moving ahead, I mainly wanted to share another experience to consider)

Got it, thank you for explaining! Yes, I can get behind that. I don't have any imminent changes following this cleanup, so checking this in is not urgent. I'll leave @nikic answer if there's something on his end.

A somewhat hacky "work-around" if we're considering keeping this in the release, but also want an earlier clean-up is to land this now and once the release is cut have a pair of revert+recommit pushed in, out of which only the revert would be cherry-picked into the release. I'm not saying this is better, just an idea.

nikic abandoned this revision.May 20 2021, 2:37 PM

I didn't have any larger plans here beyond dropping remaining dual-MSSA implementations. That was the MDA-based MemCpyOpt, and the AST-based LICM. I started here, because the LoopPM interaction makes the LICM case a bit more tricky.

But I think this may not be the best use of my time, so I'll just leave it at that :)

This revision was landed with ongoing or failed builds.Aug 7 2021, 1:36 PM