[swift-dev] inout and aliasing in the optimizer

[John McCall]

> On Dec 17, 2015, at 2:48 PM, 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 <mailto: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.

Right.

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