similar to: [RFC] lifetime.end metadata

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.

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

On Sun, May 11, 2014 at 8:19 AM, Stephan Tolksdorf <st at quanttec.com> wrote: > Hi, > > When clang/LLVM can't prove that a noexcept function only contains > non-throwing code, it seems to insert an explicit exception handler that > calls std::terminate. Why doesn't clang leave it to the eh personality > function to call std::terminate when an exception is thrown

On 5 November 2014 11:51, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Reid Kleckner" <rnk at google.com> > > To: "Philip Reames" <listmail at philipreames.com> > > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > > Sent: Wednesday, November 5, 2014 12:54:30 PM >

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

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

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 Nov 25, 2016, at 4:17 PM, Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Fri, Nov 25, 2016 at 6:10 AM, Hubert Tong <hubert.reinterpretcast at gmail.com <mailto:hubert.reinterpretcast at gmail.com>> wrote: > On Fri, Nov 25, 2016 at 1:42 AM, Daniel Berlin <dberlin at dberlin.org <mailto:dberlin at dberlin.org>> wrote:

On Dec 1, 2010, at 12:10 AM, John McCall wrote: > On Nov 30, 2010, at 11:04 PM, Bill Wendling wrote: >> • A landing pad must have exactly one dispatch instruction associated with it, >> and it must dominate that instruction. > > Okay, but how do we find it? > We can modify the dispatch to point back to the landing pad it's associated with. Something like: lpad:

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

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

Hi Reid, Is this design supposed to be able to cope with asynchronous exceptions? I am having trouble imagining how this would work without adding the ability to associate landing pads with scopes in LLVM IR. Vadim On Tue, Nov 25, 2014 at 5:27 PM, Reid Kleckner <rnk at google.com> wrote: > On Tue, Nov 25, 2014 at 3:09 PM, Kaylor, Andrew <andrew.kaylor at intel.com> > wrote:

This is a revision of the second exception handling proposal I sent out. You can see it here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-November/036484.html After much discussion, there are some changes to the proposal – some significant and some minor. One major point, this proposal does not address the issue of catching an exception thrown from a non-invoke instruction. However if done

On 5 November 2014 12:48, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Nick Lewycky" <nlewycky at google.com> > > To: "Hal Finkel" <hfinkel at anl.gov> > > Cc: "Reid Kleckner" <rnk at google.com>, "LLVM Developers Mailing List" < > llvmdev at cs.uiuc.edu> > >

On Sat, Nov 26, 2016 at 12:07 AM, Sanjoy Das <sanjoy at playingwithpointers.com > wrote: > So if you: > > 1. override operator delete to do nothing for that type (so that the > placement new actually has unfreed backing storage to re-use). > 2. have an empty destructor. > So, void *operator new(decltype(sizeof 0), void *) noexcept; struct MyInt { static void

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

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

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>

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