Strict aliasing only applies to memory operations that use strict
addresses. The optimizer needs to be aware of this flag. Uses of raw
addresses should not have their address substituted with a strict
address.
Also add Builtin.LoadRaw which will be used by raw pointer loads.
It is not valid LLVM IR to have a function call without a location to an
inlinable function inside a function with debug info — this makes it impossible
to construct inline information.
This patch adds an assertion and fixes up several places across IRGen where
such a situation could happen.
rdar://problem/26955467
For many local values we can avoid a shadow alloca by directly
describing them with a dbg.value. This also enables precise liveness
so variables don't show up in the debugger before they are
initialized. Unfortunately this also means that values will disappear
when they are no longer needed.
This patch inserts an empty inline assembler expression depending on
the llvm::Value that is being described in the blocks dominated by it.
This uses less stack space than full shadow copies *and* allows us to
track the liveness of the variable completely. It may cause values to
be spilled onto the stack, though.
<rdar://problem/26627376>
We were recovering metadata from generic boxes by reading
the instantiated payload metadata from the box's metadata,
but this approach doesn't work for fixed-size boxes, whose
metadata does not store the payload metadata at all.
Instead, emit a capture descriptor with no metadata sources
and a single capture, using the lowered AST type appearing
in the alloc_box instruction that emitted the box.
Since box metadata is shared by all POD types of the same
size, and all single-retainable pointer payloads, the
AST type might not accurately reflect what is actually in
the box.
However, this type is *layout compatible* with the box
payload, at least enough to know where the retainable
pointers are, because after all IRGen uses this type to
synthesize the destructor.
Fixes <rdar://problem/26314060>.
Now we can discern the types of values in heap boxes at runtime!
Closure reference captures are a common way of creating reference
cycles, so this provides some basic infrastructure for detecting those
someday.
A closure capture descriptor has the following:
- The number of captures.
- The number of sources of metadata reachable from the closure.
This is important for substituting generics at runtime since we
can't know precisely what will get captured until we observe a
closure.
- The number of types in the NecessaryBindings structure.
This is a holding tank in a closure for sources of metadata that
can't be gotten from the captured values themselves.
- The metadata source map, a list of pairs, for each
source of metadata for every generic argument needed to perform
substitution at runtime.
Key: The typeref for the generic parameter visible from the closure
in the Swift source.
Value: The metadata source, which describes how to crawl the heap from
the closure to get to the metadata for that generic argument.
- A list of typerefs for the captured values themselves.
Follow-up: IRGen tests for various capture scenarios, which will include
MetadataSource encoding tests.
rdar://problem/24989531
Properly lower reference counting SIL instructions with nonatomic attribute as invocations of corresponding non-atomic reference counting runtime functions.
...even if the 'self' type is generic. Additionally, Objective-C generic
types cannot be used as a source of type metadata, because Objective-C
generics are erased at runtime by default. (This may need to change.)
With these two changes, we now pass type metadata explicitly when we need
to, and /don't/ try to pass it to Objective-C methods that would have
needed it if they were Swift methods.
In 2e3c0b6, code was added to emit unique trap blocks for each
cond_fail, in order to make post-mortem debugging simpler (e.g. stack
traces have correct line/column information for the trapping location,
and it's easy to trace back to the specific jump that reaches the trap).
We didn't, however, do anything to ensure that LLVM wouldn't merge these
back together again. This is an attempt to do exactly that, after seeing
BranchFolding in the code generator merging traps into a single block.
The idea here is to emit empty inline asm strings marked as
side-effecting, and taking a unique integer argument. These come before
the trap call, so they should block any valid attempt at merging the
blocks back together.
Ideally trap would take an argument which uniquely identifies it, but
that isn't possible today.
This solution is potentially brittle in that in theory LLVM could still
merge the trap/unreachable and then branch to those after the unique asm
calls. We cannot fix that by putting another asm call after the trap,
because LLVM's CFG simplification will delete code after a trap.
rdar://problem/25216969
This occured if a stack-promoted object with a devirtualized final release is not actually allocated on the stack.
Now the ReleaseDevirtualizer models the procedure of a final release more accurately.
It inserts a set_deallocating instruction and calles the deallocator (instead of just the deinit).
This changes also includes two peephole optimizations in IRGen and LLVMStackPromotion which get rid of
unused runtime calls in case the stack promoted object is really allocated on the stack.
This fixes rdar://problem/25068118
The effect of this tiny change is that local variables will be described
by llvm.dbg.values, which will get lowered into an accurate location list
instead of a stack slot that is valid for the entire scope of the variable.
This means the debugger can now accurately track the liveness of variables
knowing exactly when they are initialized and when there values go away.
Function arguments are still kept in stack slots because (1) they are
already initialized at the function entry and (2) LLDB really needs self
to be available at all times for the expression evaluator.
This was made possible by recent advancements in LLVM such as the live
debug variables pass and various related bugfixes.
<rdar://problem/15746520>
This instruction creates a "virtual" address to represent a property with a behavior that supports definite initialization. The instruction holds references to functions that perform the initialization and 'set' logic for the property. It will be DI's job to rewrite assignments into this virtual address into calls to the initializer or setter based on the initialization state of the property at the time of assignment.
This is a hotfix for recent regressions in the LLDB testsuite caused
by lazy loading of metadata.
Long-term we will explore emitting DWARF expressions for accessing the
type metadata.
rdar://problem/24781494, SR-797
The effect of this tiny change is that local variables will be described
by llvm.dbg.values, which will get lowered into an accurate location list
instead of a stack slot that is valid for the entire scope of the variable.
This means the debugger can now accurately track the liveness of variables
knowing exactly when they are initialized and when there values go away.
Function arguments are still kept in stack slots because (1) they are
already initialized at the function entry and (2) LLDB really needs self
to be available at all times for the expression evaluator.
This was made possible by recent advancements in LLVM such as the live
debug variables pass and various related bugfixes.
<rdar://problem/15746520>
for a alloc_stack, debug_value, and debug_value_addr disagreeing on the
type of the same variable.
For -Onone, this commit is NFC.
A testcase for generic specialization will follow as soon as SIL debug
info serialization efforts are complete.
<rdar://problem/24785336>
"minimal" is defined as the set of requirements that would be
passed to a function with the type's generic signature that
takes the thick metadata of the parent type as its only argument.
We were checking for a @convention(witness_method) callee with an
abstract Self type in several places. Factor this out into a new
pair of methods on SILFunctionType, and fix the logic for static
methods, where the Self archetype is wrapped in a metatype.
remove the mixed concept that was SILFileLocation.
Also add support for a third type of underlying storage that will be used
for deserialized debug lcoations from textual SIL.
NFC
<rdar://problem/22706994>
Similarly to how we've always handled parameter types, we
now recursively expand tuples in result types and separately
determine a result convention for each result.
The most important code-generation change here is that
indirect results are now returned separately from each
other and from any direct results. It is generally far
better, when receiving an indirect result, to receive it
as an independent result; the caller is much more likely
to be able to directly receive the result in the address
they want to initialize, rather than having to receive it
in temporary memory and then copy parts of it into the
target.
The most important conceptual change here that clients and
producers of SIL must be aware of is the new distinction
between a SILFunctionType's *parameters* and its *argument
list*. The former is just the formal parameters, derived
purely from the parameter types of the original function;
indirect results are no longer in this list. The latter
includes the indirect result arguments; as always, all
the indirect results strictly precede the parameters.
Apply instructions and entry block arguments follow the
argument list, not the parameter list.
A relatively minor change is that there can now be multiple
direct results, each with its own result convention.
This is a minor change because I've chosen to leave
return instructions as taking a single operand and
apply instructions as producing a single result; when
the type describes multiple results, they are implicitly
bound up in a tuple. It might make sense to split these
up and allow e.g. return instructions to take a list
of operands; however, it's not clear what to do on the
caller side, and this would be a major change that can
be separated out from this already over-large patch.
Unsurprisingly, the most invasive changes here are in
SILGen; this requires substantial reworking of both call
emission and reabstraction. It also proved important
to switch several SILGen operations over to work with
RValue instead of ManagedValue, since otherwise they
would be forced to spuriously "implode" buffers.
This is another incremental step toward protocol resilience.
To support resiliently adding requirements with default implementations,
we need to emit the witness thunk for each default requirement once,
and share it between conformances.
However, the body of the witness thunk can call witness methods from
the conformance of <Self : P>. Formerly, witness thunks were only emitted
with a concrete Self type, so any calls were resolved statically.
Now that Self can be abstract in a witness thunk signature, we have to
pass in the witness table and do the necessary gymnastics on both sides
of the call.
At the call site, the witness table is either abstract, concrete, or
undefined, as follows:
- If the unsubstituted Self type is concrete in the witness method
signature, no witness table is necessary; this is the case of a
concrete (non-default) witness thunk.
- If the unsubstituted Self type is abstract and the substituted Self
type is concrete, the witness table is accessed via direct reference.
- If the unsubstituted Self type is abstract and the substituted Self
type is also abstract, the witness table comes from type metadata
that was passed in to the function where the call is taking place.
Inside the body of the witness method thunk, we only bind the witness
table if Self is an abstract type; this rules out the first case above,
where the witness table is not needed and cannot be provided by the
caller.
The result of a SIL witness_method instruction now lowers as an
explosion containing two values, the function pointer itself and
the witness table.
Similarly, partial application thunks now grab the witness table and
package it up in the context.
Special care is taken to support function_ref + apply and
function_ref + partial_apply of @convention(witness_method) callees;
here, we can hit the case where we don't know the original conformance
because the callee is concrete, in which case we just pass in a null
pointer as the witness table.
Witness thunks with an abstract Self currently only work for protocols
without any associated type requirements; to support those, we need
to be able to fulfill associated type metadata from the witness
table for the <Self : P> conformance. This will be addressed as part
of @rjmccall's calling convention work.
Also I didn't make any attempt to support this for @objc protocols that
do not have a witness table. In this case, the extra parameter is not
necessary since we can perform dynamic dispatch on the 'self' value to
call requirements; however, @objc protocols will not support default
implementations, at least not in the near-term.
Recent versions of LLDB can deal with line 0 locations much better and
due to a subtle bug in the heuristic instructions immediately following
the prologue could end up without debug locations which can cause serious
problems for the LLVM inliner when constructing inline debug scope info.
<rdar://problem/24394944>
As part of SE-0022, introduce an 'objc_selector' encoding for string
literals that places the UTF-8 string literal into the appropriate
segment for uniquing of Objective-C selector names.
