Avoid running a pass a second time if the pass has its own optimize-until-no-more-changes loop.
This pass property can be configured.
Currently I assume that all our function passes don't need to run a second time (without other changes in between).
It further reduces the number of pass runs by about 6%. But this improvement is cosmetic. There is no significant compile time reduction.
There are no performance changes.
Swift SVN r26760
To set the PassKind automatically, I needed to refactor some code of the pass manager and the pass definitions.
The main changes are:
1) SILPassManager now has an add-function for each pass: PM.add(createP()) -> PM.addP()
2) I removed the ARGS argument in Passes.def, which we didn't use anyway.
Swift SVN r26756
Currently the analysis invalidation API is marked as 'protected', which
means that only the pass itself can invalidate analysis. However, we have
utility functions that should invalidate analysis selectively. Exposing
the invalidation API will allow us to pass the pass to the utility and allow
it to invalidate analysis selectively.
Swift SVN r26459
The old invalidation lattice was incorrect because changes to control flow could cause changes to the
call graph, so we've decided to change the way passes invalidate analysis. In the new scheme, the lattice
is replaced with a list of traits that passes preserve or invalidate. The current traits are Calls and Branches.
Now, passes report which traits they preserve, which is the opposite of the previous implementation where
passes needed to report what they invalidate.
Node: I tried to limit the changes in this commit to mechanical changes to ease the review. I will cleanup some
of the code in a following commit.
Swift SVN r26449
In the case of a crash in the optimizer or verifier, this prints out information
about the source of the crash. This saves engineering time by allowing one to
get some quick information about the crash without needing to jump into the
buffer.
In the case of a SILFunctionTransform, this prints out the name of the function
being optimized and the name of the transform.
In the case of a SILModuleTransform, this prints out the name of the transform.
<rdar://problem/19946491>
Swift SVN r25831
PassManager.
I think this is much cleaner and more flexible. The various pass
builders have no business marshalling these things around, and they
shouldn't be bound to the pass C'tor. In the future we will be able
override and dynamically modify pass configuration this way.
Swift SVN r13626
Now the pass does not need to know about the pass manager. We also don't have
runOnFunction or runOnModule anymore because the trnasformation knows
which module it is processing. The Pass itself knows how to invalidate the
analysis, based on the injected pass manager that is internal to the
transformation.
Now our DCE transformation looks like this:
class DCE : public SILModuleTransform {
void run() {
performSILDeadCodeElimination(getModule());
invalidateAnalysis(SILAnalysis::InvalidationKind::All);
}
};
Swift SVN r13598
