similar to: [LLVMdev] Finding all values derived from a function argument

Hi Stephan, > I am trying to retrieve all instructions from a function's body that > are dependent on a specific argument. The strategy I am currently > using for that is to follow all uses of the argument and record them. > Also, whenever I encounter a store of a dependent value, I try to find > loads in the function that are dependent on that store and resume >

On Fri, Sep 24, 2010 at 2:26 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Stephan, > >> I am trying to retrieve all instructions from a function's body that >> are dependent on a specific argument. The strategy I am currently >> using for that is to follow all uses of the argument and record them. >> Also, whenever I encounter a store of a dependent

Howdy, I'm working on writing a dependence analyzer (rather like what LoopDependenceAnalysis wants to be, except a bit more general). While this is a problem of many parts, I'm currently focusing on finding pairs of memory references to test for dependence. Consider this contrived C code: double test2(int n, double *restrict A, double *restrict B, bool flag) { if (flag) { A[0] =

How can extract memory dependence among of instructions. I used the following code but it find only one dep for a instruction.I want to get all dependences for an instruction. MemoryDependenceAnalysis &mda = getAnalysis<MemoryDependenceAnalysis>(); MemDepResult mdr = mda.getDependency(inst); if (mdr.isDef()) { Instruction *dep =

Tobias, I've attached an updated patch. It contains a few bug fixes and many (refactoring and coding-convention) changes inspired by your comments. I'm currently trying to fix the bug responsible for causing a compile failure when compiling test-suite/MultiSource/Applications/obsequi/toggle_move.c; after the pass begins to fuse instructions in a basic block in this file, the aliasing

Tobias, I've attached an updated copy of the patch. I believe that I accounted for all of your suggestions except for: 1. You said that I could make AA a member of the class and initialize it for each basic block. I suppose that I'd need to make it a pointer, but more generally, what is the thread-safely model that I should have in mind for the analysis passes (will multiple threads

On Fri, 2011-12-02 at 17:07 +0100, Tobias Grosser wrote: > On 11/23/2011 05:52 PM, Hal Finkel wrote: > > On Mon, 2011-11-21 at 21:22 -0600, Hal Finkel wrote: > >> > On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: > >>> > > Tobias, > >>> > > > >>> > > I've attached an updated patch. It contains a few bug fixes

On 11/17/2011 12:38 AM, Hal Finkel wrote: > Tobias, et al., > > Attached is the my autovectorization pass. Very nice. Will you be at the developer summit? Maybe we could discuss the integration there? Here a first review of the source code. > diff --git a/docs/Passes.html b/docs/Passes.html > index 5c42f3f..076effa 100644 > --- a/docs/Passes.html > +++ b/docs/Passes.html

I show you the trace of calls to llvm that my compiler makes to generate the code above. bloques.back().last is of type Value* and bloques.back().bl is BasicBlock* (the current Block) bloques.back().last = dyn_cast<Value>(ConstantInt::get(Type::getInt32Ty(getGlobalContext()), $1, true)); // $1 is an int AllocaInst *alloc = new AllocaInst(

On 11/23/2011 05:52 PM, Hal Finkel wrote: > On Mon, 2011-11-21 at 21:22 -0600, Hal Finkel wrote: >> > On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: >>> > > Tobias, >>> > > >>> > > I've attached an updated patch. It contains a few bug fixes and many >>> > > (refactoring and coding-convention) changes inspired

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

PR43308 describes a case where StackProtector fails to protect against a fairly simple smash. This problem started after r363169, which removed StackProtector's own analysis function HasAddressTaken, and used CaptureTracking's PointerMayBeCaptured instead. The problem here is that "pointer is captured" and "pointer could be used to smash the stack" are not equivalent

Hello everybody, my problem is, that I want to get an array of pointers to all local variables in a function. This array will be used for transfering these Variables to another execution engine. I've code which generates this array, and a pointer to the target field of the array. name = variables.fname + "_pointerArray"; Instruction* pointerArray = new

Hi all, Would it be correct to say that the only instructions in LLVM IR that modify/access memory potentially are the following: (1) LoadInst : Ref (2) StoreInst : Mod (3) VAArgInst : Ref (?) (4) AllocaInst : Mod (5) MallocInst : Mod (6) FreeInst : Mod (7) CallInst : Mod/Ref ? Also, my earlier impression was that the GEP instruction only computes the effective address and does not

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

I am writing a transformation that needs to add a call to a function F() at the beginning of main() with the addresses of argc and argv as parameters to F(). However, the bytecode file I'm transforming has not allocated space on the stack for argc and argv. So, I developed my transformation to change main() from: ----- int main(int %argc, sbyte** %argv){ entry: ... // some use of

Hi, I am trying to write a simple interpreter. I am trying to generate LLVM IR for assignment operation. The code for the generation part looks like this llvm::Value* codeGenSymTab(llvm::LLVMContext& context) { > printf("\n CodeGen SymTab \n"); > Value *num = ConstantInt::get(Type::getInt64Ty(context), aTable.value, > true); > Value *alloc = new

Hi, From the file HowToUseJIT.cpp, I learned how to insert some calcuation IR code like Add/Sub/Mul etc by using Instruction *Add = BinaryOperator::createAdd(One, ArgX, "addresult", BB); By following this way, it works well when I insert some IR code whose operand is integer type like IntTy, however, when I tried to insert similar thing whose operands are float point, I got the

Prakash Prabhu wrote: > Hi all, > > Would it be correct to say that the only instructions in LLVM IR that > modify/access memory potentially are the following: > I believe that every instruction has a mayWriteToMemory()/mayReadToMemory() method that you can use to determine this information. See http://llvm.org/doxygen/classllvm_1_1Instruction.html (the LLVM doxygen info on

I used LLVM already existent passes with no problems till I tried to use MemDepPrinter.cpp : http://llvm.org/doxygen/MemDepPrinter_8cpp_source.html. I got the following segfault: llvm[0]: Compiling MyMemDepPrinter.cpp for Release+Asserts build (PIC) llvm[0]: Linking Release+Asserts Loadable Module MyMemDepPrinter.so WARNING: You're attempting to print out a bitcode file. This