[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