This is an archive of the discontinued LLVM Phabricator instance.

[Analysis] Deprecate (Legacy)DivergenceAnalysis
AbandonedPublic

Authored by Pierre-vh on Mar 27 2023, 2:47 AM.

Details

Summary

UniformityAnalysis is a superior replacement, and there are now in-tree users of those DAs left.
They will be removed in a later version. Deprecate them now so downstream users have time to change if needed.

Diff Detail

Event Timeline

Pierre-vh created this revision.Mar 27 2023, 2:47 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 27 2023, 2:47 AM
Pierre-vh requested review of this revision.Mar 27 2023, 2:47 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 27 2023, 2:47 AM

Note: I deprecated the methods instead of the classes because deprecating the classes causes warning in things like PassBuilder. I'm open to changing how we implement the deprecation if anyone has an objection :)

nikic added a subscriber: nikic.Mar 30 2023, 3:42 AM

I'd prefer deleting this code over adding pragmas. There is no need to deprecate things in C++ API before removal.

llvm/lib/Analysis/DivergenceAnalysis.cpp
93

Won't this break the GCC build?

I'd prefer deleting this code over adding pragmas. There is no need to deprecate things in C++ API before removal.

I thought we needed to deprecate the analysis first if there are downstream users. Is there a precedent for removing an analysis directly without deprecation?
If so, can you please mention it in the RFC? https://discourse.llvm.org/t/rfc-deprecate-divergenceanalysis-legacydivergenceanalysis/69538/4

I'd also rather just delete it now - especially because there's no reason not to use UA, but I thought deprecation was a mandatory step.

I'd also rather just delete it now - especially because there's no reason not to use UA, but I thought deprecation was a mandatory step.

This isn't major enough to bother deprecating. The only place we might bother with deprecation is really the C API, or long-term migrations in core APIs (e.g. the pointer element type getters)

Pierre-vh planned changes to this revision.Mar 30 2023, 4:00 AM

I'd also rather just delete it now - especially because there's no reason not to use UA, but I thought deprecation was a mandatory step.

This isn't major enough to bother deprecating. The only place we might bother with deprecation is really the C API, or long-term migrations in core APIs (e.g. the pointer element type getters)

That makes sense, I agree. Migration is also extremely straightforward for downstream users.
I added a comment on the RFC and will give it a few days in case someone has an objection, in the meantime I'll remove this from review queues.

Pierre-vh abandoned this revision.Apr 12 2023, 12:56 AM