similar to: [LLVMdev] Questions about the semantics for lifetime intrinsics...

>> Oh, I was reading "precedes/following" as having static (dominance) >> meaning. That is, in the above example you could not delete the store >> since it is not true that >> llvm.lifetime.end dominates it. >> >> Nick, is this what you had in mind? If not, then we must delete a >> matching llvm.lifetime.end, but it is not clear how we define

On 12/27/2012 12:35 PM, Rafael Espíndola wrote: >>> Oh, I was reading "precedes/following" as having static (dominance) >>> meaning. That is, in the above example you could not delete the store >>> since it is not true that >>> llvm.lifetime.end dominates it. >>> >>> Nick, is this what you had in mind? If not, then we must delete a

2017-03-31 0:54 GMT+02:00 Daniel Berlin <dberlin at dberlin.org>: > I'm curious, btw, what made it think the above is legal. > The intrinsics are marked as touching memory, having side effects, etc. The precedes my involvement with Polly. Polly has a list of intrinsics that can be safely ignored, e.g. llvm.dbg.value/llvm.gbg.declare. The lifetime markers are also in this list.

2017-03-31 1:16 GMT+02:00 Daniel Berlin <dberlin at dberlin.org>: > if you transformed > > lifetime.start(%p) > use %p > lifetime.end(%p) > into > > if (c) > lifetime.start(%p) > use %p > lifetime.end(%p) > > That is *definitely* a bug in polly. > Stack coloring should be able to handle it if that is the original IR but that is definitely not a

2017-03-31 0:19 GMT+02:00 Daniel Berlin <dberlin at dberlin.org>: >> I modified Polly's code generator to produce >> >> if (c) { >> llvm.lifetime.start(&var) >> } else { >> llvm.lifetime.start(&var) >> } >> [...] >> llvm.lifetime.end(&var) >> >> and it does not miscompile

On 12/26/2012 12:25 PM, Rafael Espíndola wrote: >> Ok, suppose you have the following code: >> BB1: >> llvm.lifetime.start(%a) >> store to %a >> llvm.lifetime.end(%a) >> br %BB2 >> >> BB2: >> <some code> >> br %BB1 >> >> If you remove the first "llvm.lifetime.start", then when you enter

> Ok, suppose you have the following code: > BB1: > llvm.lifetime.start(%a) > store to %a > llvm.lifetime.end(%a) > br %BB2 > > BB2: > <some code> > br %BB1 > > If you remove the first "llvm.lifetime.start", then when you enter > %BB1 for the second time, your "store to %a" can be considered invalid, > as you've

2017-03-31 15:00 GMT+02:00 Than McIntosh <thanm at google.com>: > Hi all, > > Just to clarify: the code I'm seeing in the stack coloring dumps is a little > different from what is being discussed in previous spots in this thread. The > example that Michael cited earlier on was > > if (c) { > llvm.lifetime.start(&var) > } > [...] >

On 12/26/2012 3:38 PM, Nick Lewycky wrote: > > Of course you can re-start memory that's been ended... if that isn't > clear in the langref, please fix. There are several things that aren't clear (at least when I read it). Case 1: block: %a = phi i32* ..., [ %a.next, %block ] llvm.lifetime.begin(4, %a) ... llvm.lifetime.end(4, %a) <-- (1) %a.next =

On 12/25/2012 1:31 PM, Alexey Samsonov wrote: > > Ok, suppose you have the following code: > BB1: > llvm.lifetime.start(%a) > store to %a > llvm.lifetime.end(%a) > br %BB2 > > BB2: > <some code> > br %BB1 > > If you remove the first "llvm.lifetime.start", then when you enter > %BB1 for the second time, your "store to

On Tue, Dec 25, 2012 at 11:09 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > On 24 December 2012 04:02, Alexey Samsonov <samsonov at google.com> wrote: > > This looks like a bug in simplifycfg. We should preserve lifetime > intrinsics > > due to the reasons I described. > > The code in //lib/Transforms/Utils/Local.cpp: > > > > if

It's useful to think about lifetime.start/end as being equivalent to a memset of undef. They effectively clobber what was there and reinitialize it with "nothing". If you transform lifetime.start in a way that would be incorrect if it were storing undef, then that transform is incorrect. On Thu, Mar 30, 2017 at 4:16 PM, Daniel Berlin via llvm-dev < llvm-dev at lists.llvm.org>

2017-03-31 13:46 GMT+02:00 Daniel Berlin <dberlin at dberlin.org>: > > > On Fri, Mar 31, 2017 at 4:05 AM, Michael Kruse <llvmdev at meinersbur.de> > wrote: >> >> 2017-03-31 1:16 GMT+02:00 Daniel Berlin <dberlin at dberlin.org>: >> > if you transformed >> > >> > lifetime.start(%p) >> > use %p >> >

On 12/26/2012 12:28 PM, Krzysztof Parzyszek wrote: > On 12/25/2012 1:31 PM, Alexey Samsonov wrote: >> >> Ok, suppose you have the following code: >> BB1: >> llvm.lifetime.start(%a) >> store to %a >> llvm.lifetime.end(%a) >> br %BB2 >> >> BB2: >> <some code> >> br %BB1 >> >> If you remove the first

Hi! I'm working on ASan option that uses llvm.lifetime intrinsics to detect use-after-scope bugs. In short, the idea is to insert calls into ASan runtime that would mark the memory as "addressable" or "unaddressable". I see the following problem with the following "trivial" basic block: for.body.lr.ph.i: ; preds = %for.body.i310

On 24 December 2012 04:02, Alexey Samsonov <samsonov at google.com> wrote: > This looks like a bug in simplifycfg. We should preserve lifetime intrinsics > due to the reasons I described. > The code in //lib/Transforms/Utils/Local.cpp: > > if (Succ->getSinglePredecessor()) { > // BB is the only predecessor of Succ, so Succ will end up with exactly > // the

This looks like a bug in simplifycfg. We should preserve lifetime intrinsics due to the reasons I described. The code in //lib/Transforms/Utils/Local.cpp: if (Succ->getSinglePredecessor()) { // BB is the only predecessor of Succ, so Succ will end up with exactly // the same predecessors BB had. // Copy over any phi, debug or lifetime instruction.

On Fri, Dec 28, 2012 at 12:35 AM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > >> Oh, I was reading "precedes/following" as having static (dominance) > >> meaning. That is, in the above example you could not delete the store > >> since it is not true that > >> llvm.lifetime.end dominates it. > >> > >> Nick, is

> Suppose you have four lifetime operations on the same address in memory, > with loads and stores all around them: > > start1--end1 .. start2--end2 > > If you remove start1 then you have a bare pointer, the memory came from > somewhere and you lose the optimization that loads before start1 become > undef, but you don't miscompile. This is assuming no looping after

Hi @all, I hit a problem with Polly-generated code which llvm.org/PR32251 . The problem is how @llvm.lifetime.start is placed after Polly transformed the code. Basically Polly transformed llvm.lifetime.start(&var) [...] llvm.lifetime.end(&var) into if (c) { llvm.lifetime.start(&var) } [...] llvm.lifetime.end(&var) now the llvm.lifetime.end is