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
Drill down into partial_apply to examine how the container pointer is
used within the partial_apply. If the uses are not unexpected, and do
not allow the container pointer to escape the partial_apply, then we'll
check how the partial_apply is used when passed into an apply by
drilling down one level into that apply (but no further). If the
partial_apply itself cannot escape the current function or any funtion
it is passed to, then we should be able to clone the partial_apply body
and rewrite it to remove the box container pointer (coming in a future
commit).
This is all effectively disabled now by passing false to the call to
canValueEscape in findUnexpectedBoxUse which disables drilling down into
the apply.
Swift SVN r15591
r15322 reworked the logic for determining where the final releases are,
which means that we no longer need to collect the uses and releases as
we evaluate candidates for promotion.
Swift SVN r15333
Promote alloc_box to alloc_stack in the case where we have multiple
releases along different paths (including paths that follow a back-edge
to the alloc_box itself).
The new approach effectively uses liveness (computed on a per-alloc_box
basis) to determine where the final release on any path will
be. Building the stdlib takes the same amount of time as it did before
this change.
Deletes 56 of the 116 remaining alloc_box in the stdlib, and speeds up
the string walk benchmark by ~8%.
Swift SVN r15322
checkAllocBoxUses had two places where mark_uninitialized was being
processed, the second one unreachable.
The code removed by this commit was the code added later, and it makes
the assumption that the mark_uninitialized is the only use of the value
being processed. Although that assumption might be reasonable and
currently true, it's not verified.
Swift SVN r14043
