[swift-dev] inout and aliasing in the optimizer

[Dave Abrahams]

Sent from my moss-covered three-handled family gradunza

> On Dec 17, 2015, at 4:52 PM, Jordan Rose via swift-dev <swift-dev at swift.org> wrote:
> 
> 
>>> On Dec 17, 2015, at 14:48, Joe Groff via swift-dev <swift-dev at swift.org> wrote:
>>> 
>>> 
>>> 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.
> 
> Do we really preserve memory safety today?

Modulo bugs, yes. Those are the intended semantics. 

> It seems like any optimizations we might do could lead to half an object getting written, which can result in memory unsafety if that object is implemented using UnsafePointer (like *cough* Array).
> 
> Jordan
> 
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20151217/6568083e/attachment.html>