search for: lifetim

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 not domi...

On 02/28/2015 10:04 AM, Björn Steinbrink wrote: > Hi, > > On 2015.02.28 10:53:35 -0600, Hal Finkel wrote: >> ----- Original Message ----- >>> From: "Philip Reames" <listmail at philipreames.com> >>>> 6. Use the lifetime.start/lifetime.end and >>>> invariant.start/invariant.end intrinsics where possible >>> Do you find these help in practice? The few experiments I ran were >>> neutral at best and harmful in one or two cases. Do you have >>> suggestions on how and when to us...

...:04 AM, Björn Steinbrink wrote: >>> Hi, >>> >>>> On 2015.02.28 10:53:35 -0600, Hal Finkel wrote: >>>> ----- Original Message ----- >>>>> From: "Philip Reames" <listmail at philipreames.com> >>>>>> 6. Use the lifetime.start/lifetime.end and >>>>>> invariant.start/invariant.end intrinsics where possible >>>>> Do you find these help in practice? The few experiments I ran were >>>>> neutral at best and harmful in one or two cases. Do you have >>>>> s...

...wrote: > On 02/28/2015 10:04 AM, Björn Steinbrink wrote: > >Hi, > > > >On 2015.02.28 10:53:35 -0600, Hal Finkel wrote: > >>----- Original Message ----- > >>>From: "Philip Reames" <listmail at philipreames.com> > >>>>6. Use the lifetime.start/lifetime.end and > >>>>invariant.start/invariant.end intrinsics where possible > >>>Do you find these help in practice? The few experiments I ran were > >>>neutral at best and harmful in one or two cases. Do you have > >>>suggestions on ho...

Hi, On 2015.02.28 10:53:35 -0600, Hal Finkel wrote: > ----- Original Message ----- > > From: "Philip Reames" <listmail at philipreames.com> > > > 6. Use the lifetime.start/lifetime.end and > > > invariant.start/invariant.end intrinsics where possible > > Do you find these help in practice? The few experiments I ran were > > neutral at best and harmful in one or two cases. Do you have > > suggestions on how and when to use them? &gt...

...k wrote: >>>> Hi, >>>> >>>>> On 2015.02.28 10:53:35 -0600, Hal Finkel wrote: >>>>> ----- Original Message ----- >>>>>> From: "Philip Reames" <listmail at philipreames.com> >>>>>>> 6. Use the lifetime.start/lifetime.end and >>>>>>> invariant.start/invariant.end intrinsics where possible >>>>>> Do you find these help in practice? The few experiments I ran were >>>>>> neutral at best and harmful in one or two cases. Do you have >>&g...

...lt;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) > } > [...] > llvm.lifetime.end(&var) > > however what I'm seeing is: > > entry block: > [...] > if (c) { // conditional branch terminating entry block > llvm.lifetime.start(&var) > [...] &gt...

I'd like to get a quick feedback on the lifetime.end metadata kind I'm considering using. I'm planning to use it in cases where lifetime.end intrinsics do not give lifetime bounds that are tight enough. As an example of when lifetime.end cannot provide a tight lifetime bound, consider the following program: void test111(int n) { if (...

>> 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 >> "matching". In the following code some executions will hit the first >> llvm.lifetime.end and others...

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

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

...>>>>> >>>>>>> On 2015.02.28 10:53:35 -0600, Hal Finkel wrote: >>>>>>> ----- Original Message ----- >>>>>>> From: "Philip Reames" <listmail at philipreames.com> >>>>>>>> 6. Use the lifetime.start/lifetime.end and >>>>>>>> invariant.start/invariant.end intrinsics where possible >>>>>>> Do you find these help in practice? The few experiments I ran were >>>>>>> neutral at best and harmful in one or two cases. Do you hav...

...el 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 >> > lifetime.end(%p) >> > into >> > >> > if (c) >> > lifetime.start(%p) >> > use %p >> > lifetime.end(%p) >> > >> > That is *definitely* a bug in polly. >> > Stack coloring s...

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 >> %BB1 for the second time, your &q...

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 same predecessors BB had. > > // Copy ove...

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 legal transform...

...itions. > > > > > 4. Mark functions as readnone/readonly/nounwind when known > > (especially for external functions) > > > > 5. Use ptrtoint/inttoptr sparingly (they interfere with pointer > > aliasing analysis), prefer GEPs > > > > 6. Use the lifetime.start/lifetime.end and > > invariant.start/invariant.end intrinsics where possible > Do you find these help in practice? The few experiments I ran were > neutral at best and harmful in one or two cases. Do you have > suggestions on how and when to use them? Good point, we should...

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

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

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 (Succ->getSinglePredecessor()) { > > // BB is the only predecessor of Succ, so Succ will end up with > exactly > > // the same predec...