(This re-applies #7736 with an update to the
tsan-inout.swift execution test to handle configurations where
TSan's ignore_interceptors_accesses is enabled by default.)
Add SILGen instrumentation to treat inout accesses as Thread Sanitizer writes.
The goal is to catch races on inout accesses even when there is a not an
llvm-level read/write to a particular address. Ultimately
this will enable TSan to, for example, report racy writes to distinct
stored properties of a common struct as a data race.
This instrumentation is off by default. It can be enabled with the
'enable-experimental-tsan-inout-instrumentation' frontend flag.
The high-level approach is to add a SIL-level builtin that represents a call
to a TSan routine in compiler-rt. Then, when emitting an address for an LValue
as part of an inout expression, we call this builtin for each path component
that represents an LValue. I've added an 'isRValue()' method to PathComponent
that tracks whether a component represents an RValue or an LValue. Right the
only PathComponent that sometimes returns 'true' is ValueComponent().
For now, we're instrumenting only InoutExprs, but in the future it probably
makes sense to instrument all LValue accesses. In this patch I've
added a 'TSanKind' parameter to SILGenFunction::emitAddressOfLValue() and
its helpers to limit instrumentation to inout accesses. I envision that this
parameter will eventually go away.
Add SILGen instrumentation to treat inout accesses as Thread Sanitizer writes.
The goal is to catch races on inout accesses even when there is a not an
llvm-level read/write to a particular address. Ultimately
this will enable TSan to, for example, report racy writes to distinct
stored properties of a common struct as a data race.
This instrumentation is off by default. It can be enabled with the
'enable-experimental-tsan-inout-instrumentation' frontend flag.
The high-level approach is to add a SIL-level builtin that represents a call
to a TSan routine in compiler-rt. Then, when emitting an address for an LValue
as part of an inout expression, we call this builtin for each path component
that represents an LValue. I've added an 'isRValue()' method to PathComponent
that tracks whether a component represents an RValue or an LValue. Right the
only PathComponent that sometimes returns 'true' is ValueComponent().
For now, we're instrumenting only InoutExprs, but in the future it probably
makes sense to instrument all LValue accesses. In this patch I've
added a 'TSanKind' parameter to SILGenFunction::emitAddressOfLValue() and
its helpers to limit instrumentation to inout accesses. I envision that this
parameter will eventually go away.
Also for class method callees, use the formal type of the base
method and not the override, fixing an issue with concrete
subclasses of generic base classes which bind a generic
parameter to a tuple type.
Fixes <https://bugs.swift.org/browse/SR-3541>.
This structure contains all of the type information that we use to build a
ResultPlanPtr. In a subsequent commit, I am going to move ResultPlanPtr creation
out of emitApply and place it before the creation of arguments. This is to
enable indirect result initializations to belong to the scope outside of any
argument based scopes.
Without this the lifetimes of the indirect result initializations and arguments
can not be separated without using hacks. There is no reason why we can't emit
the indirect result temporaries before we emit any arguments since they will
remain dormant until after the final apply/any future committed argument scopes
being popped.
rdar://30955427
ResultPlan and related constructs have already been written in a type erased
fashion. This commit takes advantage of this by moving the details of the code
to ResultPlan.{cpp,h}.
This slims down SILGenApply.cpp in a NFC way and ensures that other code in
SILGenApply can not depend on the details of ResultPlan. Also it is my hope that
this can become the beginning of the merging of the ResultPlan from SILGenApply
and from SILGenPoly. We should only have 1 way in SILGen to build applies and
create apply results.
rdar://29791263
The reason that this is being done is that:
1. SILGenFunction is passed around all throughout SILGen, including in between
APIs some of which call the SILGenFunction variable SGF and others that call it
gen.
2. Thus when one is debugging code in SILGen, one wastes time figuring out what
the variable name of SILGenFunction is in the current frame.
I did not do this by hand. I did this by:
1. Grepping for "SILGenFunction &gen".
2. By hand inspecting that the match was truly a SILGenFunction &gen site.
3. If so, use libclang tooling to rename the variable to SGF.
So I did not update any use sites.
Change emitApplyOfLibraryIntrinsic() to take a SubstitutionMap,
and use the correct abstractions to build the map.
This gets rid of the last remaining uses of gatherAllSubstitutions()
in SIL.
This is in preparation for removing the +0 self hack.
This commit in more detail does the following:
1. It adds Formal Evaluation Scopes to certain places where the scopes were
missing. Specifically:
a. The SILGenLValue cases are places where we are invoking accessors. In each
one of these cases, we had a formal evaluation scope in the accessor
itself, but we did not have a scope that closed over the base access and
the accessor access. The base access is a formal evaluation in the sense
that just like with inout bases, we must create a new reference to the
base and re-destroy the base in a chain of accesses. This is to ensure
that we do not extend the lifetime of the base inappropriately.
b. The SILGenPoly case is a place where we have never properly placed a
Formal Evaluation Scope and have completely been relying on the +0 self
hack to make sure that archetype callees are properly destroyed
immediately after a +0 call.
2. It changes all of the places in SILGen that emit self to using formal access
cleanups instead of normal cleanups.
rdar://29791263
There are many cases where getBufferForExpr and manageBufferForExpr occur right
next to each other. The closure based API expresses this pattern in a more
convenient manner where the user can express his/her intent with one action
instead of two. In these cases, the split is messy and not necessary.
The way iterated closures were used to propagate around state that caused the
flow of data in the program to be confusing to read. This makes the dataflow
explicit by communicating clearly what variables are "global" to the
computation.
Beyond the refactoring this is a NFC.
rdar://29791263
As per John, WritebackScope was always an unfortunate name. Generally these
scopes are meant for formal evaluations of inout parameters. The cases that I am
interested in generalizing them to be used for are borrows of the base of a
class that will then be used as an lvalue.
This also eliminates the out of line vector of lvalue writebacks.
rdar://29791263
