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
Currently, the pass just calls a local version of that function. After OzU, I
will enable the full pass (which is currently disabled behind a flag).
Swift SVN r21894
This will let the performance inliner inline a function even if the costs are too high.
This attribute is only a hint to the inliner.
If the inliner has other good reasons not to inline a function,
it will ignore this attribute. For example if it is a recursive function (which is
currently not supported by the inliner).
Note that setting the inline threshold to 0 does disable performance inlining at all and in
this case also the @inline(__always) has no effect.
Swift SVN r21452
*NOTE* This linkage is different from {Public,Hidden}External in that it has no
extra semantic meaning beyond shared.
The use of this linkage is to ensure that we do not serialize deserialized
shared functions. Those shared functions can always be re-deserialized from the
original module. This prevents a whole class of bugs related to the
creation of module cross references since all references to the shared
item go straight to the original module.
<rdar://problem/17772847>
Swift SVN r20375
Enable SIL parsing and SIL serialization of semantics.
We add one more field to SILFunctionLayout for semantics. We should refactor
handling of attributes at SIL level, right now they are in SILFunction as bool
or std::string and in SIL serializer as a 1-bit field or an ID field.
rdar://17525564
Swift SVN r19434
info for them and generally clean up the inline scope handling a bit.
Fix the debug scope handling for all clients of SILCloner, especially
the SIL-level spezializers and inliners.
This also adds a ton of additional assertions that will ensure that
future optimization passes won't mess with the debug info in a way that
could confuse the LLVM backend.
Swift SVN r18984
The way this pass works is very similar to generic specialization except
that it turns the old function into a thunk that calls the newly created
function that has had the dead arguments removed.
This ensures that any place in the code where we were unable to see that
the old function was being called still works and also enables us to
cut down on code size increase due to code duplication since the
marshalling code for the thunk should be very small.
This is just the first part of a larger body of work that optimizes
function signatures. The plan is to include transforming loadable
pointer args to pass by value and to convert @owned arguments to
@gauranteed arguments.
<rdar://problem/17319928>
Swift SVN r18970
