similar to: MemDep: Invalidating NonLocal result cache entries?

On Jul 28, 2008, at 3:47 PM, Prakash Prabhu wrote: > Hi, > > I have a question about the memory dependence analysis. I am trying > to use it to selectively enumerate a set of pairs of (load, store) > instructions for every function by calling getNonLocalDependency() > on the MemoryDependenceAnalysis. This populates a > DenseMap<BasicBlock*, Value*>. I just

Hi, I have a question about the memory dependence analysis. I am trying to use it to selectively enumerate a set of pairs of (load, store) instructions for every function by calling getNonLocalDependency() on the MemoryDependenceAnalysis. This populates a DenseMap<BasicBlock*, Value*>. I just looked up an usage of this in GVN.cpp: MD->getNonLocalDependency(C, deps); for

On Sep 2, 2009, at 1:07 AM, Jakub Staszak wrote: > Hello, > > I fixed my patch as you asked. Sorry for the delay, I'd been working > on my SSU patch (http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-August/025347.html > ) > > I hope that everything is fine now. Hey Jakub, Thanks for working on this again, one more round :) Please merge the three testcases into one

On Sun, 04 May 2008 16:05:44 +0000, Hendrik Boom wrote: > The languages I'm faced with compiling in the near future have nonlocal > go to statements and nested procedures. > > A procedure gets implemented as a structure containing its entry point > and an environment pointer. It is easy enough to call its entry point > and pass the environment pointer as an extra argument

The languages I'm faced with compiling in the near future have nonlocal go to statements and nested procedures. A procedure gets implemented as a structure containing its entry point and an environment pointer. It is easy enough to call its entry point and pass the environment pointer as an extra argument (rather like the pointer to this or self in object-oriented code). It's no

Hi, > The problem is with the go to statement. Again, local go to's, that go > somewhere within the same function are no particular problem -- though I > haven't studied the interaction with alloca yet; that might offer a few > surprises. The questions I have are about goto's that exit from a > function. The traditional mechanism is to implement a label as an

On Sep 2, 2009, at 3:15 PM, Chris Lattner wrote: > Please merge the three testcases into one file. We added a new > FileCheck tool which allows you to check for the exact sequence of > instructions expected, which also allows the tests to be merged into > one file. > > +/// MemCpyOpt::pointerIsParameter - returns true iff pointer is a > parameter of > +/// C call

On May 4, 2008, at 9:05 AM, Hendrik Boom wrote: > The languages I'm faced with compiling in the near future have > nonlocal goto statements and nested procedures. You want to return to a previous activation record (pascal speak) or stack frame? If yes, then yes, EH will do that for you. You'll want to understand what EH is in detail and how to map the semantics you want

Thanks for the quick reply, Owen. I went through the code in MemoryDependenceAnalysis.cpp again. Since DenseMap<BasicBlock*, Value*> maps a BasicBlock to a single Value (Instruction) and it is populated by a DFS on the reverse Control Flow Graph starting at the query instruction's block, is it correct to say that the last dependent instruction in each visited basic block is what is

Sorry, I misunderstood the question. The difference between a load and a read-only call is that load can be used as the value of the memory location. E.g. DeadStoreElimination pass removes a store that stores a just loaded value back into the same location. To do this it checks if the stored value is the value of load. Read-only call cannot be used like this. This being said, I don't know if

> On Mar 1, 2015, at 7:53 AM, Björn Steinbrink <bsteinbr at gmail.com> wrote: > > On 2015.02.28 18:17:27 -0800, Philip Reames wrote: >>> On Feb 28, 2015, at 3:01 PM, Björn Steinbrink <bsteinbr at gmail.com> wrote: >>> 2015-02-28 23:50 GMT+01:00 Philip Reames <listmail at philipreames.com>: >>>>>> On Feb 28, 2015, at 2:30 PM, Björn

Hello, I fixed my patch as you asked. Sorry for the delay, I'd been working on my SSU patch (http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-August/025347.html ) I hope that everything is fine now. -Jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: pr2218-3.patch Type: application/octet-stream Size: 7511 bytes Desc: not available URL:

Chris Lattner schrieb: > > On Aug 20, 2009, at 11:44 AM, Marc Brünink wrote: > >> Hi, >> >> I do have a FunctionPass that does change the code. This FunctionPass >> requires another FunctionPass which performs all the necessary analyses. >> This AnalysisPass again requires MemoryDependenceAnalysis. >> >> The problem is, that I would like

On Aug 21, 2009, at 3:04 AM, Marc Brünink wrote: >> This isn't really possible. The issue is that MemDep doesn't just >> "analyze your function". It is designed to be as lazy as possible, >> which means that it only does analysis when a query is performed. >> This >> means that if you have MemDep->Pass1->Pass2 and Pass2 uses MemDep

Chris Lattner schrieb: > On Aug 21, 2009, at 3:04 AM, Marc Brünink wrote: >>> This isn't really possible. The issue is that MemDep doesn't just >>> "analyze your function". It is designed to be as lazy as possible, >>> which means that it only does analysis when a query is performed. This >>> means that if you have

> On Feb 28, 2015, at 3:01 PM, Björn Steinbrink <bsteinbr at gmail.com> wrote: > > [This time without dropping the list, sorry] > > 2015-02-28 23:50 GMT+01:00 Philip Reames <listmail at philipreames.com>: > >>>> On Feb 28, 2015, at 2:30 PM, Björn Steinbrink <bsteinbr at gmail.com> wrote: >>>> >>>>> On 2015.02.28

On Mon, 05 May 2008 09:56:26 +0200, Duncan Sands wrote: > Hi, > >> The problem is with the go to statement. Again, local go to's, that go >> somewhere within the same function are no particular problem -- though >> I haven't studied the interaction with alloca yet; that might offer a >> few surprises. The questions I have are about goto's that exit

Hi, in r176827 the optimization that turns invokes with empty landing pads into plain calls was disabled for invocations of function with the "uwtable" attribute. But given this code: struct S { ~S() {}; }; void blackbox(); __attribute__((__noinline__)) void inner() { blackbox(); } int foo() { S s; inner(); return 0; } int bar() {

On Aug 20, 2009, at 11:44 AM, Marc Brünink wrote: > Hi, > > I do have a FunctionPass that does change the code. This FunctionPass > requires another FunctionPass which performs all the necessary > analyses. > This AnalysisPass again requires MemoryDependenceAnalysis. > > The problem is, that I would like MemoryDependenceAnalysis to run on > the > unaltered

[This time without dropping the list, sorry] 2015-02-28 23:50 GMT+01:00 Philip Reames <listmail at philipreames.com>: >> On Feb 28, 2015, at 2:30 PM, Björn Steinbrink <bsteinbr at gmail.com> wrote: >> >>> On 2015.02.28 14:23:02 -0800, Philip Reames wrote: >>>> On 02/28/2015 10:04 AM, Björn Steinbrink wrote: >>>> Hi, >>>>