Commit Graph

58 Commits

Author SHA1 Message Date
Michael Gottesman
1b1d90fff0 [semantic-arc] Implement simple verification of the ownership qualification of copy_value, destroy_value.
rdar://28851920
2016-10-23 00:34:26 -07:00
Michael Gottesman
a3e7bd6cad [semantic-arc] As staging detail, add a HasQualifiedOwnership flag on all SILFunctions.
Over the past day or so I have been thinking about how we are going to need to
manage verification of semantic ARC semantics in the pass pipeline. Specifically
the Eliminator pass really needs to be a function pass to ensure that we can
transparently put it at any stage of the optimization pipeline. This means that
just having a flag on the SILVerifier that states whether or not ownership is
enabled is not sufficient for our purposes. Instead, while staging in the SIL
ownership model, we need a bit on all SILFunctions to state whether the function
has been run through the ownership model eliminator so that the verifier can
ensure that we are in a world with "SIL ownership" or in a world without "SIL
ownership", never in a world with only some "SIL ownership" instructions. We
embed this distinction in SIL by creating the concept of a function with
"qualified ownership" and a function with "unqualified ownership".

Define a function with "qualified ownership" as a function that contains no
instructions with "unqualified ownership" (i.e. unqualified load) and a function
with "unqualified ownership" as a function containing such no "ownership
qualified" instructions (i.e. load [copy]) and at least 1 unqualified ownership
instruction.

This commit embeds this distinction into SILFunction in a manner that is
transparently ignored when compiling with SIL ownership disabled. This is done
by representing qualified or unqualified ownership via an optional Boolean on
SILFunction. If the Boolean is None, then SILOwnership is not enabled and the
verifier/passes can work as appropriate. If the Boolean is not None, then it
states whether or not the function has been run through the Ownership Model
Eliminator and thus what invariants the verifier should enforce.

How does this concept flow through the compilation pipeline for functions in a
given module? When SIL Ownership is enabled, all SILFunctions that are produced
in a given module start with "qualified ownership" allowing them to contain SIL
ownership instructions. After the Ownership Model eliminator has run, the
Ownership Model sets the "unqualified" ownership flag on the SILFunction stating
that no more ownership qualified instructions are allowed to be seen in the
given function.

But what about functions that are parsed or are deserialized from another
module? Luckily, given the manner in which we have categories our functions, we
can categorize functions directly without needing to add anything to the parser
or to the deserializer. This is done by enforcing that it is illegal to have a
function with qualified ownership and unqualified ownership instructions and
asserting that functions without either are considered qualified.

rdar://28685236
2016-10-21 17:37:02 -07:00
Erik Eckstein
acc2291810 AliasAnalysis: make typed based alias analysis work for ref_tail_addr 2016-09-16 11:02:19 -07:00
Dmitri Gribenko
fbb3cf35a5 Revert "New SIL instructions to support tail-allocated arrays in SIL." 2016-09-15 00:25:25 -07:00
Erik Eckstein
f83ffe6a8f AliasAnalysis: make typed based alias analysis work for ref_tail_addr 2016-09-14 14:54:18 -07:00
Arnold Schwaighofer
7e544f3658 Stop getUnderlyingObject at mark_dependence instructions for LSLocations
This helps remove redundant loads from mark_dependence instructions while our projection path can't handle them.

Fix for rdar://27138023
2016-07-01 15:02:32 -07:00
Erik Eckstein
905fd37b98 COWArrayOpt: ensure that we can hoist all address projections that we stripped.
This change is needed because we new consider index_addr as address projection in Projection.h
2016-01-27 09:04:57 -08:00
Erik Eckstein
b745691a38 SIL refactoring: Move some functions out of SILValue and Operand
SILValue.h/.cpp just defines the SIL base classes. Referring to specific instructions is a (small) kind of layering violation.
Also I want to keep SILValue small so that it is really just a type alias of ValueBase*.
NFC.
2016-01-25 10:37:03 -08:00