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
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
