similar to: Well-formed @llvm.lifetime.start and @llvm.lifetime.end intrinsics

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

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

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 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 Wed, Nov 5, 2014 at 10:01 AM, Philip Reames <listmail at philipreames.com> wrote: > Would one of you mind taking a step back and explaining what you believe > the "stack colouring problem" to be? I'm familiar with the general meaning > of the term and even some of LLVM's implementation; I'm just not sure what > specific issue you're referring to.

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

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

> 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

Here are some comments. It seems to me there are 2 (mostly separate) aspects: 1. Teaching clang how to do domination / post-domination analysis, so that the lifetime information (alloca/dealloca, or lifetime markers) can be set in the right locations in the IR. Such an analysis should be able to understand the language scopes, as well as labels / gotos and EH. The results of this analysis

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

Chris added alloca merging in the inliner a looooong time ago, 2009. The reason he added it was because at the time we didn't do stack coloring and without it we had serious stack size problems in LLVM. Since then, a few rather important things have changed: - We have reasonably powerful stack coloring support in the backend based on lifetime markers - Clang (the primary frontend I'm

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

> -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: 04 November 2014 17:16 > To: Arnaud De Grandmaison > Cc: LLVM Developers Mailing List > Subject: Re: [LLVMdev] lifetime.start/end clarification > > ----- Original Message ----- > > From: "Arnaud A. de Grandmaison" <arnaud.degrandmaison at arm.com> > > To:

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 (n < 10) { string str = "One";

On Mon, Aug 19, 2013 at 10:06 PM, Andrew Trick <atrick at apple.com> wrote: > Metadata is a better approach because it doesn’t interfere with > optimizations that are free to ignore it. > But in practice, they aren't going to be free to ignore it. If you have metadata which encodes an invariant (in the most general sense, lifetime instrinsics currently encode an invariant,

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

The existing lifetime start/end is not very well defined (by spec, or by code) in what it means, so you could have nested lifetime markers if you wanted. If you made the spec well-defined, they would be meaningful (for loops, etc). There are a number of open bugs/complaints about lifetime markers and the fact that the scope is not well defined (the spec says "This intrinsic indicates that

So, in hacking on mem2reg I noticed that it doesn't actually implement optimizations enabled by lifetime markers. I thought I might take a stab at teaching it about them, but I'm left with some questions about the semantics. Much of this may have been hash out when they were added, and if so I'll appreciate your help educating me, and maybe we can come up with improved documentation to