This didn't trigger any unused variable warnings since we always try to clean up
the contents in the ToRemove vector. Of course since the ToRemove vector is
never actually appended to, nothing ever happens there.
The other aspect of this is whether or not we actually need a ToRemove vector. I
read the code in this section and it is not necessary since the section of
GlobalOpt is only collecting information about the function we are
processing. Later after function iteration is over, we later process the data
that we filled our caches with. So no iterator invalidation can happen.
Some time ago I believe due to compile time? Not sure, we started to use
ColdBlockInfo in a per function way. So for each function, we instantiate a new
ColdBlockInfo and never use this one. So there is no reason for it to exist...
This patch both makes debug variable information it optional on
alloc_stack and alloc_box instructions, and forced variable
information on debug_value and debug_value_addr instructions. The
change of the interface uncovered a plethora of bugs in SILGen,
SILTransform, and IRGen's LoadableByAddress pass.
Most importantly this fixes the previously commented part of the
DebugInfo/local-vars.swift.gyb testcase.
rdar://problem/37720555
* CapturePropagation: Can't forward to a function if it is not swift convention compatible
This causes breakage in check-swift-optimize_size on a release stdlib
bot.
Test case to follow.
* Test case for capture propagation involving a c function
This will allow key paths to resiliently reference public properties from other binaries by referencing a descriptor vended by the originating binary. NFC yet, this just provides printing/parsing/verification of the new component.
We run GlobalOpt multiple times in the pass pipeline but in some cases object outlining shouldn't be done too early.
Having it done in a separate pass enables to run it independently from GlobalOpt.
We run GlobalOpt multiple times in the pass pipeline but in some cases object outlining shouldn't be done too early.
Having it done in a separate pass enables to run it independently from GlobalOpt.
Previously we were creating private [serialized] functions here, which
do not deserialize properly. This was only exposed by making default
argument generators PublicNonABI also.
We can just !SILFunction::hasQualifiedOwnership(). Plus as Andy pointed out,
even ignoring the functional aspects, having APIs with names this close can
create confusion.
For now these are underscored attributes, i.e. compiler internal attributes:
@_optimize(speed)
@_optimize(size)
@_optimize(none)
Those attributes override the command-line specified optimization mode for a specific function.
The @_optimize(none) attribute is equivalent to the already existing @_semantics("optimize.sil.never") attribute
@_silgen_name and @_cdecl functions are assumed to be referenced from
C code. Public and internal functions marked as such must not be deleted
by the optimizer, and their C symbols must be public or hidden respectively.
rdar://33924873, SR-6209
Transparent functions are emitted into the client in most cases, so there is no need to keep them alive in the defining module unless they are used there.
The only exception are transparent global initializers, because bodies of global initializer functions are never SIL serialized and are always IRGened into the defining module, so that clients can invoke them
This change results in small code size reductions of the binaries being produced after recent changes related to the early SIL serialization and the removal of -sil-serialize-all mode.
Fixes rdar://problem/35022861
eraseFromParent() might invalidate the iterator, so when we're
walking the pointer to the next instruction in the SILBB we end up
crashing. In order to avoid this issue, collect a SmallVector of
instructions to remove, and defer the actualy removal after we
iterated the whole SILBasicBlock, as we know it's safe.
Fixes SR-6215.
