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
Riding off of project_existential[_ref] was convenient, but the
resuls are used quite differently. Note that open_existential[_ref]
still don't print/parse reasonably yet.
Swift SVN r13878
Now the pass does not need to know about the pass manager. We also don't have
runOnFunction or runOnModule anymore because the trnasformation knows
which module it is processing. The Pass itself knows how to invalidate the
analysis, based on the injected pass manager that is internal to the
transformation.
Now our DCE transformation looks like this:
class DCE : public SILModuleTransform {
void run() {
performSILDeadCodeElimination(getModule());
invalidateAnalysis(SILAnalysis::InvalidationKind::All);
}
};
Swift SVN r13598
- purge @inout from comments in the compiler except for places talking about
the SIL argument convention.
- change diagnostics to not refer to @inout
- Change the astprinter to print InoutType without the @, so it doesn't show
up in diagnostics or in closure argument types in code completion.
- Implement type parsing support for the new inout syntax (before we just
handled patterns).
- Switch the last couple of uses in the stdlib (in types) to inout.
- Various testcase updates (more to come).
Swift SVN r13564
