Rename dealloc_ref [stack] and enable StackPromotion for OSSA

[eeckstein]

The blocker for enabling StackPromotion for OSSA was that the ownership of dealloc_ref [stack] was wrong. It should have NonUse ownership, because it's just an end-of-lifetime marker for an alloc_ref [stack].

Also, the instruction syntax dealloc_ref [stack] is very confusing, because it does not do anything like a deallocation.
It's renamed to dealloc_stack_ref , which better describes its purpose.

Renaming means: removed the [stack] flag from dealloc_ref and introduced a new instruction dealloc_stack_ref (with correct operand ownership of NonUse)

[eeckstein]

@swift-ci test

[eeckstein]

@swift-ci benchmark

[swift-ci]

Performance (x86_64): -O

Code size: -O

Performance (x86_64): -Osize

Improvement	OLD	NEW	DELTA	RATIO
FlattenListFlatMap	5634	5108	-9.3%	1.10x (?)
ObjectiveCBridgeFromNSString	1310	1210	-7.6%	1.08x (?)

Code size: -Osize

Performance (x86_64): -Onone

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: 8-Core Intel Xeon E5
  Processor Speed: 3 GHz
  Number of Processors: 1
  Total Number of Cores: 8
  L2 Cache (per Core): 256 KB
  L3 Cache: 25 MB
  Memory: 64 GB

[atrick]

Meghana fixed this here, then closed the PR:
#39803

dealloc_ref [stack] semantically deallocates stack space for a deinitialized object (of course there's no runtime deallocation for stack deallocation). dealloc_ref [stack] has has nothing to do with the object's lifetime. Except that the lifetime must obviously end before storage is deallocated.

If we care about the SIL making sense, then it would look like this:

%ref, %addr = alloc_stack_ref $Class // %ref and %addr are physically the same pointers
…
consume %ref     // in practice, this is always an @owned apply argument
dealloc_stack %addr : $Class

After devirtualization:

%ref, %addr = alloc_stack_ref $Class // %ref and %addr are physically the same pointers
…
set_deallocating %ref
end_lifetime %ref     // nop disappears after lowering ownership
dealloc_stack %addr : $Class

The OSSA lifetime utilities might end up working in practice if dealloc_stack takes the reference value as a NonUse and we're careful to check NonUse everywhere instead of isTypeDependentOperand. But there may also be places we iterate over the non-typedependent operands and assume they are real uses (which I think is a nice invariant). Again, those places could be fixed case-by-case, but that's a downside to having an illogical hack in the representation. That just needs to be weighed against the extra work involved in implementing a representation that does make sense. The PR author can decide that.

Regardless, end_stack_ref_lifetime is the wrong name because the object lifetime must end before this instruction. The instruction just marks the deallocation of stack space.

[eeckstein]

I though about the two-return-value variant of alloc_ref [stack], too. But this would be a massive change and would complicate many other parts of the SIL and optimizer. IMO we don't have to over-engineer this.

@atrick what do you think of dealloc_stack_ref? (I don't want to use the existing dealloc_stack because that's assumed to be paired to alloc_stack in so many places in the compiler)

[atrick]

I though about the two-return-value variant of alloc_ref [stack], too. But this would be a massive change and would complicate many other parts of the SIL and optimizer. IMO we don't have to over-engineer this.

That's a reasonable position. We shouldn't block forward progress on doing that work.

@atrick what do you think of dealloc_stack_ref? (I don't want to use the existing dealloc_stack because that's assumed to be paired to alloc_stack in so many places in the compiler)

Yes, that's fine!

I'm also fine with just adding a property to dealloc_stack that can be checked by the code that searches for alloc_stack. I can't imagine it's many places. And I wonder if it makes sense to be looking for alloc_ref [stack] in those cases.

Then we'd have

(1) dealloc_stack
Where a non-address argument type implies that the stack location was allocated and initialized together

(2) dealloc_stack [ref]

Has exactly same issue as #1. Just a bit more explicit

[eeckstein]

@swift-ci smoke test

[eeckstein]

@swift-ci smoke test

[eeckstein]

@swift-ci smoke test