[semantic-arc] When computing Lifetimes include all consuming uses, not just the final destroying use.

[gottesmm]

TLDR: This fixes an ownership verifier assert caused by not placing end_borrows
along paths where an enum is provable to have a trivial case. It only happens if
all non-trivial cases in a switch_enum are "dead end blocks" where the program
will end and we leak objects.

The Problem

The actual bug here only occurs in cases where we have a switch_enum on an enum
with mixed trivial, non-trivial cases and all of the non-trivial payloaded cases
are "dead end blocks". As an example, lets look at a simple switch_enum over an
optional where the .some case is a dead end block and we leak the Klass object
into program termination:

%0 = load [copy] %mem : $Klass
switch_enum %0 : $Optional<Klass>, case #Optional.some: bbDeadEnd, case #Optional.none: bbContinue

bbDeadEnd(%0a : @owned $Klass): // %0 is leaked into program end!
  unreachable

bbContinue:
  ... // program continue.

In this case, if we were only looking at final destroying uses, we would pass a
def without any uses to the ValueLifetimeChecker causing us to not have a
frontier at all causing us to not insert any end_borrows, yielding:

%0 = load_borrow %mem : $Klass
switch_enum %0 : $Optional<Klass>, case #Optional.some: bbDeadEnd, case #Optional.none: bbContinue

bbDeadEnd(%0a : @guaranteed $Klass): // %0 is leaked into program end and
                                     // doesnt need an end_borrow!
  unreachable

bbContinue:
  ... // program continue... we need an end_borrow here though!

This then trips the ownership verifier since switch_enum is a transforming
terminator that acts like a forwarding instruction implying we need an
end_borrow on the base value along all non-dead end paths through the program.

Importantly this is not actually a leak of a value or unsafe behavior since the
only time that we enter into unsafe territory is along paths where the enum was
actually trivial. So the load_borrow is actually just loaded the trivial enum
value.

The Fix

In order to work around this, I realized that the right solution is to also
include the forwarding consuming uses (in this case the switch_enum use) when
determining the lifetime and that this solves the problem.

That being said, after I made that change, I noticed that I needed to remove my
previous manner of computing the insertion point to use for arguments when
finding the lifetime using ValueLifetimeAnalysis. Previously since I was using
only the destroying uses I knew that the destroy_value could not be the first
instruction in the block of my argument since I handled that case individually
before using the ValueLifetimeAnalysis. That invariant is no longer true as can
be seen in the case above if %0 was from a SILArgument itself instead of a load
[copy] and we were converting that argument to be a guaranteed argument.

To fix this, I taught ValueLifetimeAnalysis how to handle defs from
Arguments. The key thing is I noticed while reading the code that the analysis
only generally cared about the instruction's parent block. Beyond that, the def
being from an instruction was only needed to determine if a user is earlier in
the same block as the def instruction. Those concerns not apply to SILArgument
which dominate all instructions in the same block, so in this patch, we just
skip those conditional checks when we have a SILArgument. The rest of the code
that uses the parent block is the same for both SILArgument/SILInstructions.

rdar://65244617

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

[gottesmm]

@swift-ci test

[gottesmm]

@swift-ci benchmark

[gottesmm]

I don't expect this to change anything, but just being careful.

[gottesmm]

I just moved this up partly to clean things up a little but also so I could use a decltype in the constructor so I don't have a long PointerUnion in that declaration.

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 1086aff08f5ef3b4553f20e823e6fc647ce9c1d2

[swift-ci]

Performance: -O

Code size: -O

Performance: -Osize

Regression	OLD	NEW	DELTA	RATIO
DataAppendDataMediumToMedium	4300	4720	+9.8%	0.91x (?)
Improvement	OLD	NEW	DELTA	RATIO
UTF8Decode_InitFromBytes_ascii_as_ascii	504	465	-7.7%	1.08x (?)
UTF8Decode_InitFromData_ascii_as_ascii	698	646	-7.4%	1.08x (?)

Code size: -Osize

Performance: -Onone

Regression	OLD	NEW	DELTA	RATIO
DictionaryBridgeToObjC_Access	949	1051	+10.7%	0.90x (?)

Code size: -swiftlibs

How to read the data

The tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.

If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.

Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview

  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB

[gottesmm]

@swift-ci test windows platform

[gottesmm]

@swift-ci test OS X platform

[atrick]

Great!

[gottesmm]

@swift-ci test

[gottesmm]

@swift-ci test

[gottesmm]

@swift-ci test

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 1086aff08f5ef3b4553f20e823e6fc647ce9c1d2