[swift-dev] inout and aliasing in the optimizer

[Erik Eckstein]

Hi,

I'm currently working on improving alias analysis in the optimizer and I run into following problem:

If alias analysis assumes that inout may not alias any other object, we may violate memory safety. Note that currently it's not always assumed, e.g. not in computeMemoryBehavior for apply insts.

As I understood, if the inout rule is violated, the program is not expected to behave as intended, but is still must be memory safe.
For this reason we had to insert explicit checks for inout violations in the stdlib, e.g. in ArrayBuffer: _precondition(_isNativeTypeChecked == wasNativeTypeChecked, "inout rules were violated: the array was overwritten")

Now with improved alias analysis and assuming inout-no-alias, the optimizer (specifically redundant load elimination) may eliminate these precondition checks in the stdlib.
And I can think of other cases, e.g.

sil @test(@inout %1 : $*C) {
  %2 = load %1
  apply inout_violating_function // replaces *%1 and releases the original *%1.
  %3 = load %1
  %4 = ref_element_addr %3
  %ptr = load %4
}

Redundant load elimination may optimize this to

sil @test(@inout %1 : $*C) {
  %2 = load %1
  apply inout_violating_function // replaces *%1 and releases the original *%1.
  %4 = ref_element_addr %2
  %ptr = load %4  // load pointer from freed memory
}

What I propose is to add a utility function in Types.h

inline bool isNotAliasedIndirectParameter(ParameterConvention conv,
                                          bool assumeInoutIsNotAliasing)

and optimizations, which use this function, must decide if it is safe to pass true in assumeInoutIsNotAliasing. This might be the case for high-level optimizations like COW array opts.
For alias analysis I think we have to go the conservative way.

John, Joe: any comments?

Thanks,
Erik


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20151217/813e08ae/attachment.html>