For a long time, we have:
1. Created methods on SILArgument that only work on either function arguments or
block arguments.
2. Created code paths in the compiler that only allow for "function"
SILArguments or "block" SILArguments.
This commit refactors SILArgument into two subclasses, SILPHIArgument and
SILFunctionArgument, separates the function and block APIs onto the subclasses
(leaving the common APIs on SILArgument). It also goes through and changes all
places in the compiler that conditionalize on one of the forms of SILArgument to
just use the relevant subclass. This is made easier by the relevant APIs not
being on SILArgument anymore. If you take a quick look through you will see that
the API now expresses a lot more of its intention.
The reason why I am performing this refactoring now is that SILFunctionArguments
have a ValueOwnershipKind defined by the given function's signature. On the
other hand, SILBlockArguments have a stored ValueOwnershipKind. Rather than
store ValueOwnershipKind in both instances and in the function case have a dead
variable, I decided to just bite the bullet and fix this.
rdar://29671437
I fixed a few things. Now I am finally hitting cases where we have
guaranteed/owned arguments, so I really need to do the SILGen work. But this was
a good first step.
rdar://29671437
This is just a first pass through. We know that builtins can only be used in the
standard library and trivially so only in non-generic contexts.
This means that anything that I marked trivial that isn't really will be caught
and there are very very few builtins that traffic in ownership, so I can sight
verify them.
rdar://29671437
The implementation will rely on a SILVisitor to ensure that we properly handle
all relevant cases. Right now, there are only stubs and we assert in all of
them.
rdar://29671437
These APIs work just like getParentBB does, namely they attempt to cast
self to either SILInstruction/SILArgument and if the instance is one of
those classes, using the APIs on said classes to get the relevant
Function or Module. If the dynamic casts fail, then nullptr is returned.
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.
In a bunch of use-cases we use stripSinglePredecessorArgs to eliminate this
case. There is no reason to assume that this is being done in the caller of
RCIdentity. Lets make sure that we handle this case here.
rdar://24156136
This fixes type punning issues with unsafeBitCast.
The optimizer is still too aggressive with UnsafePointer. To fix that,
we first need an explicit API for circumventing type safety
(rdar://23406272).
I should be able to fix the following regressions by migrating the
stdlib away from unsafeBitCast to unsafeReferenceCast (~2 weeks).
Slowdowns:
|.Benchmark.................|..Before.|...After.|.Speedup|
|.ArrayInClass..............|...49.00.|...78.00.|.-37.2%.|
|.Sim2DArray................|..471.00.|..549.00.|.-14.2%.|
|.PrimeNum..................|.1876.00.|.1980.00.|..-5.3%.|
Speedups:
|.Benchmark.................|..Before.|...After.|.Speedup|
|.HeapSort..................|.2962.00.|.2663.00.|..11.2%.|
|.StdlibSort................|.2672.00.|.2537.00.|...5.3%.|
We have to insert instructions that are operands *before* the instruction using
them as an operand.
Also fix a bug in the same code when looking through single predecessor basic
block arguments.
Add a testcase for all three cases.
rdar://23159379
UncheckedRefCastAddr does.
This cleans up the white-list used by ARC
optimization to be a bit more conservative.
I wasn't able to observe a change in behavior.
This fixes two issues that I ran into with the devirtualizer and also
paves the path to more simplification of the devirtualizer code.
Both issues are due to having a very liberal definition of what can be
considered an upcast.
In one case, we tunnel through an unchecked_ref_cast and then fail to
devirtualize because the source type is not a class
type (rdar://problem/20115523). We would be better off sticking to the
class type we started with.
In the other case, we tunnel through an unchecked_ref_bit_cast and this
results in an attempt to insert a checked_cast_br between unrelated
types (rdar://problem/20117782).
Swift SVN r25976
Currently, the pass just calls a local version of that function. After OzU, I
will enable the full pass (which is currently disabled behind a flag).
Swift SVN r21894
The cache is needed to ensure we do not run into compile time problems once we
start looking through Phi Nodes.
The analysis is currently disabled and just returns
SILValue::stripRCIdentityPreservingOps. I am going to thread it through the rest
of the passes that use that call. Then I am going to hide
stripRCIdentityPreservingArgs. Finally post OzU, I am going to enable the pass.
rdar://18300069
Swift SVN r21891
Originally I was using the notion of layout compatible to define the notion of a
ref count identity preserving operation. This is too restrictive of a definition
since layout compatible implies that the operation does not change the memory
location being pointed at. On the other hand, we just care that the ref counts
are the same.
rdar://18189329
Swift SVN r21613
This matches the name for SwitchEnumInst::getCaseDestination() and includes the word
'unique' so that the name self documents.
I also removed a local function doing the same work in SimplifyCFG and changed
its user to use getUniqueCaseForDestination instead.
Swift SVN r21339
