similar to: [LLVMdev] Can simplifycfg kill llvm.lifetime intrinsics?

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 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

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

On Feb 1, 2011, at 1:34 PM, Andrew Trick wrote: > On Feb 1, 2011, at 1:08 PM, Andrew Clinton wrote: > >> I have a (non-entry) basic block that contains only PHI nodes and an >> unconditional branch (that does not branch to itself). Is it always >> possible to merge this block with it's successor and produce a >> semantically equivalent program? I'm

Here's what I've got so far - it seems to work, aside from the fact that DeleteDeadPHIs is not removing at least one dead PHI in my test program. --------------------- static bool mergeBlockIntoSuccessor(BasicBlock *pred, BasicBlock *succ) { if (succ == pred) return false; if (pred->getFirstNonPHI() != pred->getTerminator()) return false; //

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

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 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

>> 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/26/2012 2:28 PM, Krzysztof Parzyszek wrote: > > The llvm.lifetime.end(%a) in your example is invalid, according to the > lang ref: Correction: it's not invalid, but if the value that %a points to is indeed never used after the store (as the lifetime.end intrinsic would indicate), then the store was dead from the beginning. Deleting the lifetime.start(%a) wouldn't have

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/28/2012 12:00 PM, Nick Lewycky wrote: > > As an alternative model, I propose replacing lifetime.start/end with a > single intrinsic that does the equivalent of 'store undef, %ptr' and > nothing more. Couldn't we just insert the store? Unless it's a volatile (or otherwise ordered) location, the optimizer would be free to remove it. -Krzysztof -- Qualcomm

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

On 12/28/2012 04:20 AM, Rafael Espíndola wrote: >> 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

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

> 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, I've been thinking about how to keep the line number with the llvm transform/Analysis passes. Basically, I agree with Chris's notes ( http://www.nondot.org/sabre/LLVMNotes/DebugInfoImprovements.txt), and I will follow his way to turn on the line number information when optimization enabled. Here is a detailed proposal: 1. Introduction At the time of this writing, LLVM's

Hi, everytime one has to add instruction at the beginning of a basic block, one has to skip past PHI nodes that are already there. How about adding a new method to BasicBlock, to get that first non-PHI instruction? So, adding an instruction will be as simple as: new SomeInstruction(............., BB->getFirstNonPHI()) Patch attached. Comments? - Volodya -------------- next part

On Sun, 4 Jun 2006, Vladimir Prus wrote: > everytime one has to add instruction at the beginning of a basic block, one > has to skip past PHI nodes that are already there. How about adding a new > method to BasicBlock, to get that first non-PHI instruction? So, adding an > instruction will be as simple as: > > new SomeInstruction(............., BB->getFirstNonPHI())