search for: lifetimes

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

...> That happens because I made the lifetime regions as small as possible, > and sometimes an alloca starts its lifetime too late for the optimization > to happen. My new (but not yet implemented) approach to to "align" the > calls to lifetime.start for allocas with overlapping lifetimes unless > there's actually a possibility for stack slot sharing. > > For example we currently translate: > > let a = [0; 1000000]; // Array of 1000000 zeros > { > let b = a; > } > let c = something; > > to roughly this: > > l...

...e I made the lifetime regions as small as possible, >>> and sometimes an alloca starts its lifetime too late for the optimization >>> to happen. My new (but not yet implemented) approach to to "align" the >>> calls to lifetime.start for allocas with overlapping lifetimes unless >>> there's actually a possibility for stack slot sharing. >>> >>> For example we currently translate: >>> >>> let a = [0; 1000000]; // Array of 1000000 zeros >>> { >>> let b = a; >>> } >>>...

...ppens because I made the lifetime regions as small as possible, > >and sometimes an alloca starts its lifetime too late for the optimization > >to happen. My new (but not yet implemented) approach to to "align" the > >calls to lifetime.start for allocas with overlapping lifetimes unless > >there's actually a possibility for stack slot sharing. > > > >For example we currently translate: > > > > let a = [0; 1000000]; // Array of 1000000 zeros > > { > > let b = a; > > } > > let c = something; >...

...mcpy optimizations. That happens because I made the lifetime regions as small as possible, and sometimes an alloca starts its lifetime too late for the optimization to happen. My new (but not yet implemented) approach to to "align" the calls to lifetime.start for allocas with overlapping lifetimes unless there's actually a possibility for stack slot sharing. For example we currently translate: let a = [0; 1000000]; // Array of 1000000 zeros { let b = a; } let c = something; to roughly this: lifetime.start(a) memset(a, 0, 1000000) lifetime.start(...

...lifetime regions as small as possible, >>>> and sometimes an alloca starts its lifetime too late for the optimization >>>> to happen. My new (but not yet implemented) approach to to "align" the >>>> calls to lifetime.start for allocas with overlapping lifetimes unless >>>> there's actually a possibility for stack slot sharing. >>>> >>>> For example we currently translate: >>>> >>>> let a = [0; 1000000]; // Array of 1000000 zeros >>>> { >>>> let b = a; >&g...

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) > } > [...] >

...ing str = "One"; cout << str; } else if (n < 100) { string str = "Two"; cout << str; } else if (n < 1000) { string str = "Three"; cout << str; } } In the program, the three local variables "str" have lifetimes that do not overlap with each other, so it should be possible to use the same stack slot for all of them to save stack space. However, clang/llvm currently allocates separate slots for each of the three variables because clang doesn't insert lifetime.end markers after the objects are destructed...

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

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

...gions as small as possible, >>>>> and sometimes an alloca starts its lifetime too late for the optimization >>>>> to happen. My new (but not yet implemented) approach to to "align" the >>>>> calls to lifetime.start for allocas with overlapping lifetimes unless >>>>> there's actually a possibility for stack slot sharing. >>>>> >>>>> For example we currently translate: >>>>> >>>>> let a = [0; 1000000]; // Array of 1000000 zeros >>>>> { >>>&gt...

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

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

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

----- Original Message ----- > From: "Philip Reames" <listmail at philipreames.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, February 27, 2015 11:25:12 PM > Subject: Re: [LLVMdev] RFC: PerfGuide for frontend authors > > > > On Feb 27, 2015, at

The LRM (http://llvm.org/docs/LangRef.html#llvm-lifetime-start-intrinsic) essentially states that: - ptr is dead before a call to "lifetime.start size, ptr" - ptr is dead after a call to "lifetime.end size, ptr" This is all good and fine, and the expected use case is that all "lifetime.end size, ptr" markers are matched with a preceding "lifetime.start

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

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