[PATCH] D52307: [LoopRotate] Fix lifetime handling.
Florian Hahn via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Sep 20 13:29:21 PDT 2018
fhahn added a comment.
In https://reviews.llvm.org/D52307#1240955, @efriedma wrote:
> Duplicating lifetime.start and lifetime.end intrinsics isn't fundamentally a problem, as long as they stay correctly paired. What is this supposed to solve?
My understanding from the LangRef was that having 2 set of lifetimes for the same memory location may lead to unexpected behaviour. For lifetime.start, the semantics are described as
> This intrinsic indicates that before this point in the code, the value of the memory pointed to by ptr is dead. This means that it is known to never be used and has an undefined value. A load from the pointer that precedes this intrinsic can be replaced with 'undef'.
So if we duplicate lifetimes and say we have
%tmp = bitcast i32* %m to i8*
call void @llvm.lifetime.start.p0i8(i64 4, i8* nonnull %tmp)
%v1 = load i32* %m
call void @llvm.lifetime.end.p0i8(i64 4, i8* nonnull %tmp)
br label %bb2
.....
bb3:
call void @llvm.lifetime.start.p0i8(i64 4, i8* nonnull %tmp)
%v1 = load i32* %m
call void @llvm.lifetime.end.p0i8(i64 4, i8* nonnull %tmp)
br label %exit
Now when visiting bb3, we see the lifetime.start and can replace any loads that precedes it (%v1) with undef. lifetime.end says something similar about stores after lifetime.end. Maybe I am missing something from the LangRef?
This seems to be causing a runtime failure in our internal benchmarks.
https://reviews.llvm.org/D52307
More information about the llvm-commits
mailing list