[swift-dev] inout and aliasing in the optimizer

[Joe Groff]

> On Dec 17, 2015, at 2:34 PM, Erik Eckstein via swift-dev <swift-dev at swift.org> wrote:
> 
> 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?

I agree that we can't make a blanket assumption that inout is noalias. Arnold made a similar conclusion last year, so I think we already treat them as aliasing. IRGen won't apply the LLVM noalias attribute to inout parameters, for instance. It's probably better to target `inout` with specific known-acceptable optimizations (load forwarding, writeback elimination, transforming to input-result pair, etc.) than generally treating it as noalias.

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