[LLVMdev] lifetime.start/end clarification

[Arnaud A. de Grandmaison]

From: Reid Kleckner [mailto:rnk at google.com] 
Sent: 05 November 2014 22:49
To: Philip Reames
Cc: Arnaud De Grandmaison; LLVM Developers Mailing List
Subject: Re: [LLVMdev] lifetime.start/end clarification

 

On Wed, Nov 5, 2014 at 11:17 AM, Philip Reames <listmail at philipreames.com> wrote:

 

On 11/05/2014 10:54 AM, Reid Kleckner wrote:

This seems fine to me.  The optimizer can (soundly) conclude that %p is dead after the "lifetime.end" (for the two instructions), and dead before the "lifetime.start" (for the *single* instruction in that basic block, *not* for the previous BB).  This seems like the proper result for this example, am I missing something?

 

What if I put that in a loop, unroll it once, and prove that the lifetime.start is unreachable? We would end up with IR like:

 

loop:

  ... use %p

  call void @lifetime.end( %p )

  ... use %p

  call void @lifetime.end( %p )

  br i1 %c, label %loop, label %exit

 

Are the second uses of %p uses of dead memory?

It's hard to discuss this without being specific about the starting IR and transforms.  My general response is that either a) such a transform wouldn't be valid or b) the behaviour of the original program was undefined.  

 

The starting IR would be something that jumps into the middle of a lifetime region, like the example that Arnaud gave. This was assuming the current state of the world where we haven't added a second lifetime start call prior to the goto branch.

 

Start with something like:

 

void f(int x) {

  while (x) {

    goto skip_start;

    {

      int y; // lifetime.start

skip_start:

      y = g();

      x -= y;

      // lifetime.end

    }
  }
}

 

The block containing the lifetime start of y is unreachable and can be deleted.

 

On this example, I think the critical edge to the skip_start label need to get a lifetime.start inserted (btw, we already insert there a gep to the alloca to solve a dominator issue), and this makes sense because such an edge also contains (in essence) the trivial constructors of the scope where the label is.

 

This looks to me as a hint that when they are used with an alloca, lifetime.start/end really have to be paired, and that all possible uses of the alloca should be covered by a [start,end] :

- In the above testcase, when the path from lifetime.end is walked-up the cfg, it reaches the alloca, and this is weird.

- In my testcase, when the paths from lifetime.start and lifetime.end are walked-up the cfg, it becomes inconsistent in the entry block: one path will tell it’s dead, the other it’s alive.

This puts the burden onto clang to generate consistent marker info, which sounds reasonable after all.

 

I can probably add some checks to enforce this in llvm, or at least detect such cases: this will definitely help me to spot candidates for the miscompilation I observe, which by the way is not caused by unnamed temporaries, but by standard VarDecl + lifetime markers. I do not know yet where though. It means that we have a lurking bug today in-tree, and changing the size threshold for marker insertion is enough to trigger it.

 

Cheers,

Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141106/181e231b/attachment.html>