[PATCH] D27031: [PM] Change the static object whose address is used to uniquely identify analyses to have a common type which is enforced rather than using a char object and a `void *` type when used as an identifier.

Chandler Carruth via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 22 18:36:15 PST 2016


chandlerc created this revision.
chandlerc added a reviewer: rsmith.
chandlerc added a subscriber: llvm-commits.
Herald added subscribers: david2050, mzolotukhin, mcrosier, mehdi_amini, sanjoy.

This has a number of advantages. First, it at least helps some of the
confusion raised in Justin Lebar's code review of why `void *` was being
used everywhere by having a stronger type that connects to documentation
about this.

However, perhaps more importantly, it addresses a serious issue where
the alignment of these pointer-like identifiers was unknown. This made
it hard to use them in pointer-like data structures. We were already
dodging this in dangerous ways to create the "all analyses" entry. In
a subsequent patch I attempted to use these with TinyPtrVector and
things fell apart in a very bad way.

And it isn't just a compile time or type system issue. Worse than that,
the actual alignment of these pointer-like opaque identifiers wasn't
guaranteed to be a useful alignment as they were just characters.

This change introduces a type to use as the "key" object whose address
forms the opaque identifier. This both forces the objects to have proper
alignment, and provides type checking that we get it right everywhere.
It also makes the types somewhat less mysterious than `void *`.

We could go one step further and introduce a truly opaque pointer-like
type to return from the `ID()` static function rather than returning
`AnalysisKey *`, but that didn't seem to be a clear win so this is just
the initial change to get to a reliably typed and aligned object serving
is a key for all the analyses.

Thanks to Richard Smith and Justin Lebar for helping pick plausible
names and avoid making this refactoring many times. =]

While here, I've tried to move away from the "PassID" nomenclature
entirely as it wasn't really helping and is overloaded with old pass
manager constructs. Now we have IDs for analyses, and key objects whose
address can be used as IDs. Where possible and clear I've shortened this
to just "ID". In a few places I kept "AnalysisID" to make it clear what
was being identified.


https://reviews.llvm.org/D27031

Files:
  include/llvm/Analysis/AliasAnalysis.h
  include/llvm/Analysis/AssumptionCache.h
  include/llvm/Analysis/BasicAliasAnalysis.h
  include/llvm/Analysis/BlockFrequencyInfo.h
  include/llvm/Analysis/BranchProbabilityInfo.h
  include/llvm/Analysis/CFLAndersAliasAnalysis.h
  include/llvm/Analysis/CFLSteensAliasAnalysis.h
  include/llvm/Analysis/CallGraph.h
  include/llvm/Analysis/DemandedBits.h
  include/llvm/Analysis/DependenceAnalysis.h
  include/llvm/Analysis/DominanceFrontier.h
  include/llvm/Analysis/GlobalsModRef.h
  include/llvm/Analysis/IVUsers.h
  include/llvm/Analysis/LazyCallGraph.h
  include/llvm/Analysis/LazyValueInfo.h
  include/llvm/Analysis/LoopAccessAnalysis.h
  include/llvm/Analysis/LoopInfo.h
  include/llvm/Analysis/MemoryDependenceAnalysis.h
  include/llvm/Analysis/ModuleSummaryAnalysis.h
  include/llvm/Analysis/ObjCARCAliasAnalysis.h
  include/llvm/Analysis/OptimizationDiagnosticInfo.h
  include/llvm/Analysis/PostDominators.h
  include/llvm/Analysis/ProfileSummaryInfo.h
  include/llvm/Analysis/RegionInfo.h
  include/llvm/Analysis/ScalarEvolution.h
  include/llvm/Analysis/ScalarEvolutionAliasAnalysis.h
  include/llvm/Analysis/ScopedNoAliasAA.h
  include/llvm/Analysis/TargetLibraryInfo.h
  include/llvm/Analysis/TargetTransformInfo.h
  include/llvm/Analysis/TypeBasedAliasAnalysis.h
  include/llvm/IR/Dominators.h
  include/llvm/IR/PassManager.h
  include/llvm/IR/Verifier.h
  include/llvm/Transforms/Utils/MemorySSA.h
  lib/Analysis/AliasAnalysis.cpp
  lib/Analysis/AssumptionCache.cpp
  lib/Analysis/BasicAliasAnalysis.cpp
  lib/Analysis/BlockFrequencyInfo.cpp
  lib/Analysis/BranchProbabilityInfo.cpp
  lib/Analysis/CFLAndersAliasAnalysis.cpp
  lib/Analysis/CFLSteensAliasAnalysis.cpp
  lib/Analysis/CallGraph.cpp
  lib/Analysis/DemandedBits.cpp
  lib/Analysis/DependenceAnalysis.cpp
  lib/Analysis/DominanceFrontier.cpp
  lib/Analysis/GlobalsModRef.cpp
  lib/Analysis/IVUsers.cpp
  lib/Analysis/LazyCallGraph.cpp
  lib/Analysis/LazyValueInfo.cpp
  lib/Analysis/LoopAccessAnalysis.cpp
  lib/Analysis/LoopInfo.cpp
  lib/Analysis/MemoryDependenceAnalysis.cpp
  lib/Analysis/ModuleSummaryAnalysis.cpp
  lib/Analysis/OptimizationDiagnosticInfo.cpp
  lib/Analysis/PostDominators.cpp
  lib/Analysis/ProfileSummaryInfo.cpp
  lib/Analysis/RegionInfo.cpp
  lib/Analysis/ScalarEvolution.cpp
  lib/Analysis/ScalarEvolutionAliasAnalysis.cpp
  lib/Analysis/ScopedNoAliasAA.cpp
  lib/Analysis/TargetLibraryInfo.cpp
  lib/Analysis/TargetTransformInfo.cpp
  lib/Analysis/TypeBasedAliasAnalysis.cpp
  lib/IR/Dominators.cpp
  lib/IR/PassManager.cpp
  lib/IR/Verifier.cpp
  lib/Passes/PassBuilder.cpp
  lib/Transforms/Utils/MemorySSA.cpp
  unittests/Analysis/CGSCCPassManagerTest.cpp
  unittests/Analysis/LoopPassManagerTest.cpp
  unittests/IR/PassManagerTest.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D27031.79014.patch
Type: text/x-patch
Size: 52593 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161123/fc4f1fe0/attachment.bin>


More information about the llvm-commits mailing list