This commit adds a flag to disable optimizations on a specific functions. The
primary motivation of this patch is to allow the optimizer developers to reduce
testcasese by disabling optimizations of parts of the code without having to
recompile the compiler or inspect SIL. The annotations "inline(never)"
and "optimize.none" can go a long way.
The second motivation for this patch is to allow our internal adopters to work
around compiler bugs.
rar://19745484
Usage:
@semantics("optimize.never")
public func miscompile() { ... }
Swift SVN r27475
Previous attempts to update the callgraph explicitly after calls to
linkFunction() weren't completely effective because we can deserialize
deeply and introduce multiple new function bodies in the process.
This gets us a bit closer, but only adds new call graph nodes. It does
not currently add edges for everything that gets deserialized (and this
is not fatal, so it is a step forward).
Swift SVN r27120
These aren't really orthogonal concerns--you'll never have a @thick @cc(objc_method), or an @objc_block @cc(witness_method)--and we have gross decision trees all over the codebase that try to hopscotch between the subset of combinations that make sense. Stop the madness by eliminating AbstractCC and folding its states into SILFunctionTypeRepresentation. This cleans up a ton of code across the compiler.
I couldn't quite eliminate AbstractCC's information from AST function types, since SIL type lowering transiently created AnyFunctionTypes with AbstractCCs set, even though these never occur at the source level. To accommodate type lowering, allow AnyFunctionType::ExtInfo to carry a SILFunctionTypeRepresentation, and arrange for the overlapping representations to share raw values.
In order to avoid disturbing test output, AST and SILFunctionTypes are still printed and parsed using the existing @thin/@thick/@objc_block and @cc() attributes, which is kind of gross, but lets me stage in the real source-breaking change separately.
Swift SVN r27095
Use FullApplySite rather than ApplyInst through data structures and
function signatures.
This change does not update the call graph to actually look at
TryApply. That will happen in a future change.
Swift SVN r26893
Before this commit, passes that were attempting to maintain the call
graph would actually build it if it wasn't already valid, just for the
sake of maintaining it.
Now we only maintain it if we already had a valid call graph built.
Swift SVN r26873
Before the change the RCIdentityAnalysis kept a single map that contained
the module's RC information. When function passes needed to invalidate the
analysis they had to clear the RC information for the entire module. The
problem was mitigated by the fact that we process one function at a time, and
we start processing a new function less frequently.
II adopted the DominanceAnalysis structure. We should probably implement
this functionality as CRTP.
Swift SVN r26636
Small tweak to function signature optimization so that it filters out
applies that might have multiple targets, as well as applies of partial
applies, which will take some updates to handle.
Resolves rdar://problem/19632244 and rdar://problem/20049782.
I've opened rdar://problem/20306331 to consider handling
apply-of-partial-apply at some point in the future.
Swift SVN r26585
We no longer need or use it since we can always refer to the same bit on
the applied function when deciding whether to inline during mandatory
inlining.
Resolves rdar://problem/19478366.
Swift SVN r26534
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
Re-apply r26072 with a fix to ensure that we get stable bottom-up
orderings in the call grpah.
Using SmallPtrSet here makes sense, and paves the way to more reasonable
code for editing the call graph by clients.
One unfortunate casualty of this is the ArrayRevView that was used by
one client.
Swift SVN r26093
This reverts commit r26072, which could result in non-deterministic
bottom-up ordering in the call graph.
I'll reapply with a fix soon.
Swift SVN r26074
It makes more sense, and paves the way to more reasonable code for
editing the call graph by clients.
One unfortunate casualty of this is the ArrayRevView that was used by
one client.
Swift SVN r26072
With the improvements I have made to the ARC optimizer, these are no longer
necessary. This will give us an idea if guaranteed is being respected properly
without enabling +0 self.
The main effect that this could cause are use-after-frees. I checked with guard
malloc and asan that we are not performing any use-after-frees on the
PerfTestSuite and asan with ninja check.
Swift SVN r25654
Small clean-up to try to improve on the clarity of the call graph code.
I think this is an overall improvement although there is still some
clunky naming that could be improved in the future.
Swift SVN r25492
We could explode or dce the argument. Make sure we change the calling convention
of the specialized method if we do so.
rdar://19733030
Swift SVN r25030
This will have an effect on inlining into thunks.
Currently this flag is set for witness thunks and thunks from function signature optimization.
No change in code generation, yet.
Swift SVN r24998
Previously I was using a large SmallVector to create Nodes for the
ProjectionTree. This created an issue when the SmallVector would convert
from small to large representation in the middle of a method on an
object that is stored in the SmallVector. Thus the 'this' pointer will
be invalidated and all sorts of fun times will occur.
I switched now to using a BumpPtrAllocator which is passed into the tree
and used in FunctionSignatureOptimization for all projection trees.
<rdar://problem/19534462>
Swift SVN r24706
1. Eliminate unused variable warnings.
2. Change field names to match capitalization of the rest of the field names in the file.
3. Change method names to match rest of the file.
4. Change get,set method for a field to match the field type.
Swift SVN r24501
I do not think that function signature opts is the right place to handle
promotion of @in, @out arguments. The right place to do such things is when we
perform specialization. That is the natural place to do it since that is where
we transition from address only to loadable types.
Swift SVN r23940
I am starting to reuse manglings for different passes. I want to make sure that
when we reuse functions we actually get a function created by the same pass.
Swift SVN r23924
The underlying problem is that e.g. even if a method is private but its class is public, the method can be referenced from another module - from the vtable of a derived class.
So far we handled this by setting the SILLinkage of such methods according to the visibility of the class. But this prevented dead method elimination.
Now I set the SILLinkage according to the visibility of the method. This enables dead method elimination, but it requires the following:
1) Still set the linkage in llvm so that it can be referenced from outside.
2) If the method is dead and eliminated, create a stub for it (which calls swift_reportMissingMethod).
Swift SVN r23889
Now all SIL function specialization passes use the new mangling infrastructure.
Lets keep it that way for future passes as well. = ).
Implements:
<rdar://problem/18831609>
Fixes:
<rdar://problem/19065735>
<rdar://problem/18906781>
<rdar://problem/18956916>
Swift SVN r23859
This reverts commit r23715 because it breaks the build of the
StrSplitter.swift benchmark, hitting an assert about deleting a function
with references.
Swift SVN r23725
The reason why I am interested in doing this is that:
1. Performing partial dead argument elimination is just a good thing to
do since it reduces dead opaque uses of explosion values, helping other
optimizations.
2. By performing SROA on function arguments, I am able to avoid having
to teach the ARC optimizer about aggregates in arguments. It is
important to try to keep the ARC optimizer as slim as possible.
Additionally the projection tree infrastructure that was built for this
optimization will also allow me to easily "trim" and explode indirect
arguments as well.
On my machine I am seeing the following speedups:
Dictionary3||||||||||-33.53%
Dictionary2||||||||||-19.20%
StringBuilder||||||||-11.04%
StdlibSort|||||||||||-9.82%
StringInterpolation||-9.82%
rdar://17005816
Swift SVN r23587
I also renamed ArgumentDescriptor::addNewArguments() =>
ArgumentDescriptor::addCallerArgs() to match addThunkArgs. This name fits better
and gives both concepts distinct names.
Swift SVN r23507
This allows me to SROA arguments without messing with any of the rest of
the machinery in FunctionSignatureOpts since now the main machinery of
FunctionSigOpts manipulates ArgumentDescriptors instead of SIL directly.
Swift SVN r23500
This means that:
1. I can make the ConsumedArgToEpilogueReleaseMatcher a local variable
instead of being on the FunctionAnalyzer class. This will be done in a
latter commit.
2. When I SROA arguments, I always put the fix_lifetime, release_value
on the correct argument by reusing old values. In the case of creating
the thunk, I use the thunks arguments which are the same as the old args
and I use the argument list of the old ApplyInst in the caller functions
before I delete the old ApplyInst. This means that when I SROA the
arguments of a function, the @owned => @guaranteed argument will work
without any changes.
Swift SVN r23499
Given a function F, this utility class attempts to match up owned arguments with
releases in the epilogue of the function.
I am refactoring this from FunctionSigOpts so I can use it in the ARC optimizer.
<rdar://problem/18923030>
Swift SVN r23219
without a valid SILDebugScope. An assertion in IRGenSIL prevents future
optimizations from regressing in this regard.
Introducing SILBuilderWithScope and SILBuilderwithPostprocess to ease the
transition.
This patch is large, but mostly mechanical.
<rdar://problem/18494573> Swift: Debugger is not stopping at the set breakpoint
Swift SVN r22978
This reverts commit r22965. I forgot to commit some necessary LLVM changes to
MapVector before committing this. These have hit trunk now so I am recommitting.
Swift SVN r22973
The main change was to create a FunctionAnalyzer structure which stores
all of the data that we carry around. This reduces the number of
arguments for a bunch of functions and also enables the beginning of a
split in the pass in between the analysis part and the execution
part. There are still some things I need to clean up which I will do in
a little bit.
Swift SVN r22962
