> On Dec 17, 2015, at 2:34 PM, Erik Eckstein via swift-dev
> <swift-dev@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
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
