similar to: [LLVMdev] lifetime.start/end clarification

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

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

Just moving this branch of the thread out of the review because I don't want to derail the review thread... Kostya - why are these two cases not optimization bugs in general? (why do they only affect sanitizers?) On Mon, Nov 18, 2013 at 8:37 PM, Kostya Serebryany <kcc at google.com> wrote: > And we've been just informed by the mozilla folks about yet another case > of

On Tue, Nov 19, 2013 at 8:25 PM, David Blaikie <dblaikie at gmail.com> wrote: > Just moving this branch of the thread out of the review because I don't > want to derail the review thread... > > Kostya - why are these two cases not optimization bugs in general? (why do > they only affect sanitizers?) > The recent case from mozilla (

The root cause of those issues is the fact that sanitizers verify C++-level semantics with LLVM IR level instrumentation. For example, speculative loads are OK in IR if it can be proved that the load won't trap, but in C++ it would be a data race. On Tue, Nov 19, 2013 at 8:38 PM, Kostya Serebryany <kcc at google.com> wrote: > > > > On Tue, Nov 19, 2013 at 8:25 PM, David

On Tue, Nov 19, 2013 at 9:05 PM, Kuperstein, Michael M < michael.m.kuperstein at intel.com> wrote: > My $0.02 - I'm not sure the transformation introduces a data race. > > To the best of my understanding, the point of the C++11/C11 memory model > is to allow a wide array of compiler transformations - including > speculative loads - for non-atomic variables. > I believe

On Tue, Nov 19, 2013 at 8:38 AM, Kostya Serebryany <kcc at google.com> wrote: > > > > On Tue, Nov 19, 2013 at 8:25 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> Just moving this branch of the thread out of the review because I don't >> want to derail the review thread... >> >> Kostya - why are these two cases not optimization bugs in

What I'm trying to say is that according to my understanding of the C++11 memory model, even in that small reproducer, the store to g and the load from g are in fact a data race. (This is regardless of the fact the load is protected by a branch that is not taken.) From: Kostya Serebryany [mailto:kcc at google.com] Sent: Tuesday, November 19, 2013 19:46 To: Kuperstein, Michael M Cc: Evgeniy

My $0.02 - I'm not sure the transformation introduces a data race. To the best of my understanding, the point of the C++11/C11 memory model is to allow a wide array of compiler transformations - including speculative loads - for non-atomic variables. I believe what's most likely happening (without looking at the Mozilla source) is that the original program contains a C++ data race, and

On Tue, Nov 19, 2013 at 10:08 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Kostya Serebryany" <kcc at google.com> > > To: "Michael M Kuperstein" <michael.m.kuperstein at intel.com> > > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > > Sent: Tuesday, November 19,

----- Original Message ----- > From: "Kostya Serebryany" <kcc at google.com> > To: "Michael M Kuperstein" <michael.m.kuperstein at intel.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Tuesday, November 19, 2013 11:45:39 AM > Subject: Re: [LLVMdev] Curiosity about transform changes under Sanitizers (Was:

----- Original Message ----- > From: "David Blaikie" <dblaikie at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Kostya Serebryany" <kcc at google.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Tuesday, November 19, 2013 12:19:46 PM > Subject: Re: [LLVMdev] Curiosity about transform

On Tue, Nov 19, 2013 at 9:56 PM, Kuperstein, Michael M < michael.m.kuperstein at intel.com> wrote: > What I’m trying to say is that according to my understanding of the > C++11 memory model, even in that small reproducer, the store to g and the > load from g are in fact a data race. > > (This is regardless of the fact the load is protected by a branch that is > not

It seems there is no -enable-iv-rewrite now in llvm3.2, and it suggest -enable-load-pre, but it still does not work. So, how to active the transform? -- View this message in context: http://llvm.1065342.n5.nabble.com/indvars-issues-tp4646p58587.html Sent from the LLVM - Dev mailing list archive at Nabble.com.

Hello . I'm trying to implement FunctionPass for detecting loops in llvm IR. How can I get <condition> for loop from llvm::Loop object.? Is there any example? Thanks in advance, Edvard  -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120723/85e7f2f9/attachment.html>

Hi, InstCombine canonicalizes index operands (unless they are into struct types) to pointer size. The comment says: "If we are using a wider index than needed for this platform, shrink it to what we need. If narrower, sign-extend it to what we need. This explicit cast can make subsequent optimizations more obvious.". For our architecture, the canonicalization is a bit

Hi, We recently found a testcase showing that simplifications in instcombine sometimes change the instruction without reducing the instruction cost, but causing problems in TwoAddressInstruction pass. And it looks like the problem is generic and other simplification may have the same issue. I want to get some ideas about what is the best way to fix such kind of problem. The testcase:

I'd missed the fact that j wasn't just being decremented. This isn't as easy as I said. Philip On 03/03/2016 02:36 PM, Philip Reames via llvm-dev wrote: > SCEV should be able to easily prove that j is positive here. I'm not > sure where the right place to use that information would be in this > case. Sanjoy, can you comment? > > Philip > > On 03/03/2016

Hi, is there any standard way to figure out the label of the basic block where a conditional branch merges? If we have a branch statement without an else part this is straightforward: br i1 %cmp, label %if.then, label %if.end, !dbg !24 We only need to check the operand names whether they contain "end". However things are getting more complex when there is an else branch and in

Hello all, I just noticed that LLVM has trouble recognizing nested simple select operations. My testcase is as follows: -------------------------- snip ------------------------------ #include <stdio.h> int main(int argc, char **argv) { int a; scanf("%d", &a); a = a > 255 ? 255 : a < 0 ? 0 : a; printf("A: %d\n", a); return 0; }