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
Previously, we used shared linkage and did not specialize fragile functions
since this exposed serialization issues. These serialization issues have been
dealt with but I realized the model did not make sense: We do not specialize
functions with "external" linkage. This means that we only specialize functions
in the module in which it is defined. Thus shared provides no benefit in terms
of the linker being able to squash the function. Instead we just copy whatever
linkage the original function used.
rdar://16917049
Swift SVN r22940
This reverts r22923, which doesn't actually compile. The fix is probably
obvious (s/F/this/) but I didn't want to mess with it in case it's wrong.
Swift SVN r22933
This patch ensures that if we already have a version of a function with
an optimized function signature, we do not turn the original function
into a thunk or change the original function to call the already created
specialized version of it. The reason for doing this is:
1. It enables us to avoid the question of whether or not the callee and
caller properly mesh. To do this safely, we would really need to analyze
the specialized version of the function to make sure that it
meshes. This could be fragile.
2. This situation should not occur often since we only run function
signature specialization once in the pipeline and we do not specialize
external functions (* see below) implying linking will not affect this
optimization.
* We do not specialize functions with external linkage since:
1. Linking in a function to the current module does not provide any more
information about the internals or the signature of the function that
was available in the original module.
2. For function signature optimization to work, we need to be able to
optimize both the caller and the callee. External functions are not
emitted into the final object file implying that any changes we make to
the caller or callee will not be apparent in the final object file. So
we will not get any optimization benefit and could potentially introduce
miscompiles.
Swift SVN r22609
convert the current Function to a thunk. This ensures we can ignore whether or
not the function was originally a thunk which could potentially be fragile. This
should only occur rarely so we should not be doing more work in the common case.
Swift SVN r22600
The sets not being considered are:
1. Any functions that will always be inlined. We ignore the inlined case since we can just
optimize the signature of the caller at each of the given function call sites.
2. Functions that have already been specialized once.
3. External functions. This is because for function signature
optimization to work, we need to be able to modify the caller and the
callee. Thus if the caller or callee is external since we can not modify
the external definition, we can not perform any specialization.
4. Generic functions. I am leaving this for a later iteration.
5. Non-Fragile functions. I am leaving this for a later iteration.
6. ObjCMethods and Witness Methods. We can never perform this
optimization on ObjCMethods and I am going to enable witness methods in
a later iteration.
7. Functions without call sites. Since we are only specializing fragile
functions, if a function without call sites is used in a different module, that
module will be able to deserialize it. Once I handle non-fragile functions, this
will change.
Swift SVN r22564
the debug scope of each instruction to be the debug scope of the new
function.
This will be tested by the functionality in function signature opts.
Swift SVN r22553
llvm::Optional lives in "llvm/ADT/Optional.h". Like Clang, we can get
Optional in the 'swift' namespace by including "swift/Basic/LLVM.h".
We're now fully switched over to llvm::Optional!
Swift SVN r22477
Now the SILLinkage for functions and global variables is according to the swift visibility (private, internal or public).
In addition, the fact whether a function or global variable is considered as fragile, is kept in a separate flag at SIL level.
Previously the linkage was used for this (e.g. no inlining of less visible functions to more visible functions). But it had no effect,
because everything was public anyway.
For now this isFragile-flag is set for public transparent functions and for everything if a module is compiled with -sil-serialize-all,
i.e. for the stdlib.
For details see <rdar://problem/18201785> Set SILLinkage correctly and better handling of fragile functions.
The benefits of this change are:
*) Enable to eliminate unused private and internal functions
*) It should be possible now to use private in the stdlib
*) The symbol linkage is as one would expect (previously almost all symbols were public).
More details:
Specializations from fragile functions (e.g. from the stdlib) now get linkonce_odr,default
linkage instead of linkonce_odr,hidden, i.e. they have public visibility.
The reason is: if such a function is called from another fragile function (in the same module),
then it has to be visible from a third module, in case the fragile caller is inlined but not
the specialized function.
I had to update lots of test files, because many CHECK-LABEL lines include the linkage, which has changed.
The -sil-serialize-all option is now handled at SILGen and not at the Serializer.
This means that test files in sil format which are compiled with -sil-serialize-all
must have the [fragile] attribute set for all functions and globals.
The -disable-access-control option doesn't help anymore if the accessed module is not compiled
with -sil-serialize-all, because the linker will complain about unresolved symbols.
A final note: I tried to consider all the implications of this change, but it's not a low-risk change.
If you have any comments, please let me know.
Swift SVN r22215
