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
TerminatorInsts. Now you can walk over the successor list of a terminator
and actually modify the SILSuccessor directly, allowing better CFG
transformations. NFC.
Swift SVN r26140
When we specialize a partial_apply to remove boxes that were arguments
to the partial_apply, we release the box explicitly (since it will no
longer get released as part of releasing the partial_apply).
We were putting these releases before the partial_apply, only worked
properly in cases where those releases were not the final release of the
box.
With this commit we now release the box at each point where the
partial_apply goes dead.
Fixes rdar://problem/17892969.
Swift SVN r25177
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
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
Recent name mangling changes resulted in AllocBoxToStack cloning the
referenced function of a partial apply once for every reference (i.e. we
would end up with N copies within the cloned function if there were N
references).
Fix this by checking for an already existing function *outside* of the
cloner rather than inside of it.
Swift SVN r24005
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
In allocbox-to-stack we were cloning closures to remove box parameters
but in the process we were also removing the release on the box. We
still need to release it so that if it is the last reference anything it
owns gets released.
This change inserts the release before the partial_apply.
Fixes rdar://problem/17872402.
Swift SVN r23876
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
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
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
Don't crash in the case where we cannot find the final release of a box
along every return path. Instead, just bail out on promoting that box.
<rdar://problem/17455386>
Swift SVN r20874
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
hierarchy. I still need to figure out a reliable way to write testcases
for this. For now it's ensured via an assertion in SILCloner::postprocess.
Swift SVN r18917
Update the box-to-stack promotion pass to place the newly promoted
allocations at the function entry, and deallocations before each return.
Ideally we would scope these lifetimes down, but it's a bit challenging
because:
- The capture promotion pass can insert releases, and these releases
are not in any particular order with respect to the box creation.
- The box-to-stack promotion pass has for a while now been promoting
boxes that are arguments to partial_apply when we know the
partial_apply doesn't escape the current function. To correctly
place the deallocs, we would need to determine the potential
lifetimes of the allocated data, e.g. the last use of the
partial_apply along any given path.
I have opened <rdar://problem/16723128> so that we can try to improve
this in the future.
Fixes <rdar://problem/16242937>.
Swift SVN r16852
The implied semantics are:
- side-effects can occur any time before the first invocation.
- all calls to the same global_init function have the same side-effects.
- any operation that may observe the initializer's side-effects must be
preceded by a call to the initializer.
This is currently true if the function is an addressor that was lazily
generated from a global variable access. Note that the initialization
function itself does not need this attribute. It is private and only
called within the addressor.
Swift SVN r16683
Implement JoeG's suggestion to limit the examination of uses to the
container pointer since there is no legal way for the address pointer to
outlive the box container.
Deletes 16 of the 45 alloc_box in the stdlib in my build
configuration.
canValueEscape() can be simplified now since it is only being used
examine how partial_apply get used, but I'll leave that for a separate
commit.
Swift SVN r16047
Attempt to promote boxes to stack allocations by examining partial_apply
instructions that the boxes appear as arguments in, and then if things
look good examining the apply that the partial_apply is passed to in
order to ensure the partial_apply is not captured. If it looks like we
can legally promote the box, clone the partially applied function to
remove the box container pointer, and rewrite the partial_apply.
Fixes <rdar://problem/16373639>.
Swift SVN r15727
For the partial_apply instructions we'll rewrite to use stack operands,
we need to remove the box pointer operands when specializing the applied
functions and rewriting the partial_apply.
This is another commit with no current effect - we do not specialize
yet, and do not promote any additional boxes to stack locations.
Swift SVN r15719
Given an operand to an apply/partial_apply, we want to get the BB
argument in the body of the called function that represents the operand.
Swift SVN r15609
