similar to: [LLVMdev] A minor improvement: dyn_cast + iterators

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

I can confirm that both are compiled properly: A) PHINode *PN; for (BasicBlock::iterator I = H->begin(); PN = dyn_cast<PHINode>(I); I++) .... B) 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

Hi all, Here the first bunch of patch for compiling part of LLVM under win32 with MSVC 7.1: * Trivial addings (I hope!): - #include <string> at top of: llvm\include\llvm\ExecutionEngine\ExecutionEngine.h(78) : error C2039: 'string' : is not a member of '_STL' - #include <algorithm> at top of: llvm\lib\CodeGen\LiveIntervalAnalysis.cpp(639) : error C2039:

On Fri, Sep 03, 2004 at 03:01:01PM -0500, Anshu Dasgupta wrote: > ><snip> > >for (BasicBlock::iterator I = Dest->begin(); PHINode *PN = > >dyn_cast<PHINode>(I); ++I) > > visitPHINode(*PN); > ><snip> > > > >build_vc71\lib\Transforms\Scalar\SCCP.cpp(202) : error C2275: > >'llvm::PHINode' : illegal use of this type as

Hi Paolo, > <snip> > for (BasicBlock::iterator I = Dest->begin(); PHINode *PN = > dyn_cast<PHINode>(I); ++I) > visitPHINode(*PN); > <snip> > > build_vc71\lib\Transforms\Scalar\SCCP.cpp(202) : error C2275: > 'llvm::PHINode' : illegal use of this type as an expression > > but I think is a NO-NO, so suggestions? Since it's fussy

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

In the section expaining "dyn_cast" There are following lines of code: if (AllocationInst *AI = dyn_cast<AllocationInst>(Val)) { ... } I cannot understand how you take a operand, a value, and cast it into a Instruction. Can you explain it for me? Another common example is: // Loop over all of the phi nodes in a basic block BasicBlock::iterator BBI =

On Thu, 28 Jul 2005, Naftali Schwartz wrote: > I now understand that IndVarSimplify.cpp is capable of reproducing array > references when the pointer initialization from the array address is found > inside the immediately enclosing loop, such that in the following code: Ok. > int A[20000], B[100], Z; > int main() > { > int i, j, *a, *b; > for ( a =

Also sprach xli3 at uiuc.edu: } In the section expaining "dyn_cast" } There are following lines of code: } if (AllocationInst *AI = dyn_cast<AllocationInst>(Val)) { } ... } } } I cannot understand how you take a operand, a value, and cast } it into a Instruction. Can you explain it for me? } } Another common example is: } } // Loop over all of the phi nodes

I now understand that IndVarSimplify.cpp is capable of reproducing array references when the pointer initialization from the array address is found inside the immediately enclosing loop, such that in the following code: int A[20000], B[100], Z; int main() { int i, j, *a, *b; for ( a = &A[0], i = 0; i != 200; i++ ) for ( b = &B[0], j = 0; j != 100; j++

I guess I thought that once I redirected the branches and created new PHIs that LLVM would correct the variable usage when I return true (changed CFG) from the pass. Is this not the case? On Wed, Mar 7, 2012 at 4:08 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Here is the code snippet that I am using to create the PHIs in the loop > according to the PHIs in the new preheader. At

Here is the code snippet that I am using to create the PHIs in the loop according to the PHIs in the new preheader. At this point I have already redirected the loop backedge and removed the preheader from the loop. for (BasicBlock::iterator II = loopHeaderBB->begin(); (PN=dyn_cast<PHINode>(II)); ++II) { // remove loop back PHI and add it to split BB

Hi folks, Hope this is not a silly question. But it bothers me when I am thinking about it. My question is: 1. In the implementation of serverSplitPHINodes(), why it only checks the first PHI node for possible multiple inputs from outside the region to extract. There could be more than one PHI nodes in the header block, and the code only checks the first one. I don't quite get it.

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

Hi all, I was trying to implement an obfuscation tool for C-code on the basis of LLVM. I got a prototype of the simple obfuscation transformation which converting control flow graph to something like a state machine. I am not sure I will have time to work on extending further this tool with new transformations like opaque predicates and decided to put here source code I have by now with hope

Hi Surinder, I don't see anything obviously wrong with your code. I suggest that (1) you build LLVM with assertions enabled, (2) you run the verifier on your bitcode, and (3) run your program under valgrind. Ciao, Duncan. > I am getting a segmentation fault as soon as I touch the Basic block > *b value defined as : > > std::string getPHIAssigns(const PHINode *PH) > {

I am getting a segmentation fault as soon as I touch the Basic block *b value defined as :  std::string getPHIAssigns(const PHINode *PH)  { const BasicBlock *b = PH->getParent();    errs() << b->size(); where as getPHIAssigns is being called from               for (BasicBlock::iterator ins=b->begin(), e3=b->end(); ins!=e3; ++ins, ++l) // get instructions                

Hi all, I wrote code that compiled with llvm 2.8, but now I'm using llvm 2.9 and it doesn't compile anymore: My code looks like this: User *U; ... if (PHINode * phi = dyn_cast<PHINode>(U)) { ... BasicBlock * Pred = phi->getIncomingBlock(I); ... } And when I compile it with clang: Live.cc:130:27: error: member access into

Hi, I got a problem when I am trying to add a dummy basic block. Let say there are two blocks, A and B. A----->B I am trying to generate new BB called C which is located between A and B, but not break the edge of AB. The graph is like the following A---->B \ / \ / C There is new BB 'C' with edges AC and CB. It is kind of like what breakcriticaledge pass does.

Hi again, It's partially done. My concern is that it won't be accepted as is because of adding the flag parameter in a lot of places. I'd like to show what it looks like (here, not on llvm-commit yet), maybe someone could suggest a better way. There are two sources of the flag: field of TargetOptions and function attribute. I had to add the later one for InstCombine pass. Still