similar to: [LLVMdev] #uses

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

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

void MetaSplit::handleProgramUses(Value *V){ if(!isa<BasicBlock>(V)) programValues.insert(V); if(User *U = dyn_cast<User>(V)){ User::op_iterator OB = U->op_begin(), OE = U->op_end(); for(; OB != OE; ++OB){ if(CallInst *CI = dyn_cast<CallInst>(*OB)){ Function *F = CI->getCalledFunction(); if(F == ii || F == fi || F == vi || F == di || F == ci

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

Hi, I try to iterate over all uses of a Function with the following code (simplified): for (Value::use_iterator UI = F->use_begin(), UE = F->use_end(); UI != UE; ++UI) { if (CallInst* I = dyn_cast<CallInst>(*UI)) { // do something interesting } } This works on Linux, but on Windows the dyn_cast fails, even though the only use of F in that

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

Thanks for the reply. For the source code: int main() { int a = 0; int *p; p = &a; call_arnamoy(p); int *p1; p1 = p; return 1; } The bit code: %retval = alloca i32, align 4 %a = alloca i32, align 4 %p = alloca i32*, align 8 %p1 = alloca i32*, align 8 store i32 0, i32* %retval store i32 0, i32* %a, align 4 store i32* %a, i32** %p, align 8 %0 = load i32** %p, align 8 %call = call i32

The enlosed patch for IndVarSimplify.cpp works even when the pointer increment is deeply nested wrt pointer initialization, but note that it needs to have loop structures preserved, as in the following: int A[3000000], B[20000], C[100], Z; volatile int I, J, K; int main() { int i, j, k, *a, *b, *c; for ( a = &A[0], i = 0; i != 300; i++ ) { I++;

On Fri, 3 Sep 2004, Paolo Invernizzi wrote: > I can confirm that both are compiled properly: Ok. > for (BasicBlock::iterator I = H->begin; isa<PHINode>(I); I++) { > PHINode *PN = cast<PHINode(I); > .... > } > > I'll make a patch for whatever solution do you prefer (this problem is > a showstopper for more than a dozen files...) I prefer this

On Tue, 17 Jul 2007, Zhongxing Xu wrote: > I am doing inter-procedural static analysis, so I need to do DFS of call > graph. llvm-gcc sometimes generates this kind of call instruction, which > cause the call graph to be incomplete. > > But thanks for your information, instcombine really solves the problem. Happy to help. You'll probably find that other optimizations help as

Here's what I've got so far - it seems to work, aside from the fact that DeleteDeadPHIs is not removing at least one dead PHI in my test program. --------------------- static bool mergeBlockIntoSuccessor(BasicBlock *pred, BasicBlock *succ) { if (succ == pred) return false; if (pred->getFirstNonPHI() != pred->getTerminator()) return false; //

Thanks for providing me with those examples. My rather inefficient pass, which inherits from ModulePass, currently iterates through the Module, Functions, and BasicBlocks multiple times (once to find strcpy, another to find strcat, and so on for various other functions). If I only care about the direct calls, would I benefit more from switching to multiple use_iterators or the InstVisitor

This is just a quick note the let everyone know dyn_cast now works properly with BasicBlock::iterator's and others. In other words, you can now do things like this: for (BasicBlock::iterator I = BB.begin(); PHINode *PN = dyn_cast<PHINode>(I); ++I) ... instead of this: for (BasicBlock::iterator I = BB.begin(); PHINode *PN = dyn_cast<PHINode>(&*I); ++I) ...

It appears dereferencing the use iterator returned the "user" in older LLVM versions. See the following commit to Use.h. You can see that the intention is to return the "user". So this is not the behavior anymore. https://github.com/llvm-mirror/llvm/commit/d1fe495464e4abc384565813cbf1cb8b130e5a6d - // Retrieve a pointer to the current User.- UserTy *operator*() const {-

I am doing inter-procedural static analysis, so I need to do DFS of call graph. llvm-gcc sometimes generates this kind of call instruction, which cause the call graph to be incomplete. But thanks for your information, instcombine really solves the problem. On 7/17/07, Chris Lattner <sabre at nondot.org> wrote: > > On Thu, 12 Jul 2007, Zhongxing Xu wrote: > > The current

Hi Sanjoy, the first and last patches look good (except that you didn't add any tests for the auto-upgrade functionality). Comments on the other two below. > Attached patches split init.trampoline into adjust.trampoline and > init.trampoline, like in gcc. > > As mentioned in the previous mail, I've not made a documentation > patch, since I'm not sure about what the

Hello, I've been hung up on some issues for several weeks now, and some of them seem to stem from GetElementPtr instructions. Say we have a Definition: *%29 = getelementptr inbounds [10 x i32]* @c, i32 0, i32 %28* Now, I'd like to see the uses of that definition. In my code, I do this twice, in slightly different ways. This first method works and shows instructions that use %29:

Hi, I have some basic questions. I'd appreciate if you can help me with them. 1. In the LLVM programmer manual, section "Finding call sites: a slightly more complex example", there is such piece of code: ------------------------------------------------- class OurFunctionPass : public FunctionPass { public: OurFunctionPass(): callCounter(0) { } virtual

On Thu, 12 Jul 2007, Zhongxing Xu wrote: > The current BasicCallGraph will miss call sites like this: > %tmp86 = call i8* (...)* bitcast (i8* ()* @find_ispell to i8* (...)*)( ) > ; <i8*> [#uses=1] > > Here the direct user of @find_ispell is a ConstantExpr. > I added several lines of code to address this case. > Below is the output of command: svn diff

Hi, I have the following piece of code: %34 = fptosi float %33 to i32 %35 = call i32 @function(i32 %34) nounwind I would like of know how can I duplicate the statement %35 ? , as follows: %34 = fptosi float %33 to i32 %35 = call i32 @function(i32 %34) nounwind *%36 = **call i32 @function(i32 %34) nounwind* * * i.e, two instructions exactly equal. Using clone, results in badref. Moreover, how