SILCombine: don't sink forwarding instructions with address operands

[eeckstein]

We don't do memory lifetime analysis for this peephole optimization. Therefore we can't risk sinking instructions with address operands out of the addressed memory's lifetime.

For example:

  %3 = mark_dependence %2 on %1 : $*T  // must not be moved after the destroy_addr
  destroy_addr %1

Fixes a verifier crash
rdar://166240751

[eeckstein]

@swift-ci smoke test

[xedin]

@swift-ci please test source compatibility release

[atrick]

This is probably necessary just to quiet the memory verifier until it can recognize all the uses of dependent values as uses of the original address.
Ideally the verifier would not accept the incoming SIL:

  %4 = mark_dependence %0 on %2
  destroy_addr %2
  destroy_value %4

It is illegal because it deinitializes a dependent value after deinitializing the value that it depends on.

What pass created the bad SIL pattern? And can we have a separate bug for that?

[eeckstein]

good point

What pass created the bad SIL pattern? And can we have a separate bug for that?

This SIL comes directly out of SILGen for an ObjectiveC method call which takes a inout argument. Originally it looks like (after DI):

  %54 = alloc_stack [lexical] [var_decl] $Optional<NSString>, var, name "type", type $Optional<NSString>
  ...
  %57 = begin_access [modify] [static] %54
  ...
  %74 = mark_dependence %73 on %57
  store %74 to [assign] %57

Where the [assign] destroys the original value in %57.

The source code:

                var type: NSString?
                let dictionary = depthData.dictionaryRepresentation(forAuxiliaryDataType: &type)

where depthData is an AVDepthData