This enables one to dump the various passpipelines in a yaml format. Other
pretty print formats can be added in the future as well if desired. Its intended
usage is to provide a source of pass pipeline information for external python
bug-reducing tools. By integrating this as a compiler-tool, we are guaranteed to
never have to update any of these tools in the face of passpipeline changes.
We also either remove or make private the addPass* functions on SILPassManager,
so the only way to execute passes via SILPassManager is by creating a
SILPassPipelinePlan. This beyond adding uniformity ensures that we always
resetAndRemoveTransformations properly after a pipeline is run.
This commit adds the functionality, but does not change SILPassManager to use
it. The reason why I am doing this is so I can implement sil-opt pass bisecting
functionality in python using a tool that dumps the current pass pipelines
out. This will ensure that even in the face of changes to the pass pipelines,
everything should just work.
This is a simple refactoring to make it really easy for me to rip out the pass
pipeline code into a real pass pipeline class that can be
serialized/deserialized. By serializing/deserializing the pass-pipeline
directly, it becomes very easy to write a bug-point like tool in python on top.
Additionally, it allows users who want to manipulate the pipeline by hand to be
able to easily dump out the normal pass pipeline without any work.
This is a hidden option. It should be used like: -assume-single-threaded
When this function is provided, the compiler assumes that the code will be executed in the single threaded mode. It then performs certain optimizations that can benefit from it, e.g. it marks as non-atomic all reference counting instructions in the user code being compiled.
Often times SILGen wants to hold onto values that have been copied. This causes
an issue, when due to Cleanups firing, SILBuilder inserts destroys and destroys
the copy that produced the value that SILGen held onto. This will then cause
SILGen to emit incorrect code.
There really is no reason to introduce such complexity into SILBuilder when a
small simple guaranteed pass can perform the same work. Thus the introduction of
this pass.
In a later commit, I am going to eliminate the SILBuilder entry points.
rdar://28685236
This is a NFC change, since verification still will be behind the flag. But this
will allow me to move copy_value, destroy_value in front of the
EnableSILOwnership flag and verify via SILGen that we are always using those
instructions.
rdar://28851920
Previously I was going to just set a flag and run the verifier once with that
flag enabled. Then I realized that given that the OwnershipModelEliminator is a
function pass, I really need to put the state on whether or not ownership is
enabled on functions. Now this commit refactors the verifier to use the state on
the function when determining if it should allow for ownership qualified
instructions or not in a specific function.
rdar://28685236
radar rdar://problem/28434323
SILGen has no reason to insert shadow copies for inout parameters any more. They cannot be captured. We still emit these copies. Sometimes deshadowing removes them, but sometimes it does not.
In this PR we just avoid emitting the copies and remove the deshadowing pass.
This PR chery-picked some of @dduan work and built on top of it.
When SILVerifyAll is enabled, individual functions are verified after
function passes are run upon them. This means that any functions created
by a function pass will not be verified after the pass runs. Thus
specialization errors that cause the verifier to trip will be
misattributed to the first pass that makes a change to the specialized
function. This is very misleading and increases triage time.
This change eliminates that problem by ensuring that when SILVerifyAll is
enabled, we always verify newly specialized functions as they are added to the
worklist.
rdar://28706158
An int is already constant and in general in LLVM style we do not create such
const ints. On the other hand, a constexpr I think expresses the intent slightly
better and gives the compiler more freedom anyways.
This adds the typedef and switches uses of NodeType * to NodeRef. This is in
preparation for the eventual NodeRef-ization of the GraphTraits in LLVM. NFC.
This consists of 3 parts:
1) Extend CallerAnalysis to also provide information if a function is partially applied
2) A new DeadArgSignatureOpt pass, similar to FunctionSignatureOpts, which just specializes for dead arguments of partially applied functions.
3) Let CapturePropagation eliminate such partial_apply instructions and replace them with a thin_to_thick conversion of the specialized functions.
This optimzation improves benchmarks where static struct or class functions are passed as a closure (e.g. -20% for SortStrings).
Such functions have a additional metatype parameter. We used to create a partial_apply in this case, which allocates a context, etc.
But this is not necessary as the metatype parameter is not used in most cases.
rdar://problem/27513085
This re-instates commit de9622654d
The problem of the infinite loop should be fixed by the previous fix in FunctionSignatureOpts.
In addition this new commit implements a safety check to void such cases, even if buggy optimizations try to keep pushing new functions onto the work list.
Instead the pipeline is continued on the old function. This happens when a pass pushes a new, e.g. specialized function, on the function stack.
There is no need to repeat passes which already did run on a function.
It saves a little of compile time and I didn't see any significant impact on code size or performance.
It also simplifies the pass manager.
This ensures that when one is bisecting on pass counts, regardless of whether or
not one removes code in the test case, the pass counts being run remain the
same.
The option is supposed to be used as follows and takes a comma-seprataed list of SIL pass numbers as input:
-Xllvm -debug-only-pass-number=passnumber1[,passnumber2,..,passnumberN]
It enables the debug printing (i.e. prints inside DEBUG statements ) when one of the mentioned passes is being run.
For details see the comment in ConditionForwarding.cpp.
This optimization pass helps to optimize loops iterating over closed ranges, e.g. for i in 0...n { }
I'm measuring around a 1% reduciton in compile time for the stdlib, with
a handful of improvements on the benchmarks when compiled at -O, and one
small regression on one benchmark.
Without this we can end up not inlining in some trivial cases.
For example, the ClosureSpecializer may generate a function_ref - convert_function - apply sequence.
This must be cleaned up by SILCombine before we can inline the function.
rdar://problem/22309472
We can remove the retain/release pair preceeding the builtins based on the
knowledge that the lifetime of the reference is guaranteed by someone hanging on
to the reference elsewhere.
