The SCCPSolver is using a structure (AnalysisResultsForFn) where it keeps
pointers to various analyses needed by the IPSCCP pass. These analyses are
requested all at the same time, which can become problematic in some cases.
For example one could be retrieved via getCachedAnalysis() prior to the
actual execution of the analysis. In more detail:
The IPSCCP pass uses a DomTreeUpdater to preserve the PostDominatorTree
in case the PostDominatorTreeAnalysis had run before IPSCCP. Starting with
commit 1b1232047e83b the IPSCCP pass may use BlockFrequencyAnalysis for
some functions in the module. As a result, the PostDominatorTreeAnalysis
may not run until the BlockFrequencyAnalysis has run, since the latter
analysis depends on the former. Currently, we setup the DomTreeUpdater
using getCachedAnalysis to retrieve a PostDominatorTree. This happens
before BlockFrequencyAnalysis has run, therefore the cached analysis can
become invalid by the time we use it. To solve this problem we must
request the PostDominatorTree after BlockFrequencyAnalysis runs.
Had been nice if one could just do something like this here:
I.e. just use getCachedResult to see if there is a DT/PDT analysis available. If so, we need to update corresponding analyses. If they aren't available we shouldn't run the analysis here.
I think that would work if getCachedResult actually picks up an analysis that is created during the pass execution (any reason why it wouldn't do that?).
Just saying that the PassManager/AnalysisManager should know if PDT has been calculated (so having a map in FunctionSpecialization that keep track of if BlockFrequencyAnalysis has been run seems a bit off, as what we want to know is if the DominatarTree/PostDominiatorTree needs to be updated).
So a solution like this would be more future proof (if it is working) as it wouldn't need to know which other analyses that might end up calculating the PDT.