similar to: [LLVMdev] newbi to llvm - how to get array size

John, I have looked at the SAFECode and thought following sould work if (isa<Constant>(I.getOperand(0))) { Out << "*** operand 0 is a constant ******"; if (Instruction *operandI = dyn_cast<Instruction>(I.getOperand(0))) { Out << "********operand is an instruction ****"; if (GetElementPtrInst *gepI =

John, I have looked at the real code (instead of the obsolete one) and it appears to be easy to find if an operand is a getelementptr instruction. if (ConstantExpr * CE = dyn_cast<ConstantExpr>(I.getOperand(0))) { Out<< "*** operand 0 is a constant Expr******"; if (CE->getOpcode() == Instruction::GetElementPtr) { Out<< "*** operand 0 is

On 1/21/2011 10:46 PM, Surinder wrote: > John, > > I have looked at the SAFECode and thought following sould work > > if (isa<Constant>(I.getOperand(0))) > { Out<< "*** operand 0 is a constant ******"; > if (Instruction *operandI = dyn_cast<Instruction>(I.getOperand(0))) > { Out<<

On 1/20/2011 10:02 PM, Surinder wrote: > When I compile C programs into llvm, it produces load instructions in > two different flavours. > > (1) %8 = load i8** %bp, align 8 > > (2) %1 = load i8* getelementptr inbounds ([4 x i8]* @.str, i64 0, > i64 0), align 1 > > I know that %bp in first case and the entire "getelementptr inbounds > ([4 x i8]* @.str, i64

When I compile C programs into llvm, it produces load instructions in two different flavours. (1) %8 = load i8** %bp, align 8 (2) %1 = load i8* getelementptr inbounds ([4 x i8]* @.str, i64 0, i64 0), align 1 I know that %bp in first case and the entire "getelementptr inbounds ([4 x i8]* @.str, i64 0, i64 0)" in second case can be obtained by dump'ing I.getOperand(0)

Hi Sam, Thanks for your reply. I am implementing my research (http://www.it.usyd.edu.au/~suri/Detecting%20Buffer%20Over.pdf), a translation of LLVM to a simple non-deterministic language to detect buffer overflows. It involves (1) printing a control flow graph of basic blocks of a function (easily done) (2) translating each llvm statement to a corresponding data flow language (needs ASTs to

Hello Surinder, The existing hand-written parser is callable from almost anywhere so the only reason you'd need to have a parser for it would be to extend it. Originally it was written using Flex and Bison but Chris Lattner rewrote it from scratch to catch more errors at the parsing stage. The only feature I've found to be missing from the existing LLVM-AS utility was an include

Hi Surinder, Did you remember to #include "llvm/Analysis/Dominators.h"? Best, Douglas On Sun, Jan 30, 2011 at 11:24 PM, Surinder <surifilms at gmail.com> wrote: > I am creating a new pass (function pass) called Dfl from the Hello > example and notes on "Writing an LLVM Pass". When I compile the > program I get inncomplete type error

Hi Surinder, You'll need to dereference your iterator to get a pointer: const BasicBlock *p = *pr; Cheers, Lang. On Mon, Jan 31, 2011 at 3:04 PM, Surinder <surifilms at gmail.com> wrote: > I have a pointer to a basic block and am iterating thru its > predecessor blocks. I want to get a pointer to the predecessor block. > How do I do it. I am using following code and it

Has anyone written a grammar for LLVM for ANTLR. I mean an ANTLR grammar that parses LLVM instructions. Is an LLVM grammar available for any other parsing tool? Surinder

I am creating a new pass (function pass) called Dfl from the Hello example and notes on "Writing an LLVM Pass". When I compile the program I get inncomplete type error (llvm/include/llvm/Pass.h:188: error: incomplete type 'llvm::DominatorTree' used in nested name specifier). The code is given below. Surinder struct Dfl : public FunctionPass { raw_ostream *Out; static

llvm/include/llvm/Pass.h:93: llvm::Pass::Pass(llvm::PassKind, intptr_t): Assertion `pid && "pid cannot be 0"' failed. On Mon, Jan 31, 2011 at 3:55 PM, Surinder <surifilms at gmail.com> wrote: > I have written a new pass, it compiles ok but crashes when i run it > with error (llvm::Pass::Pass(llvm::PassKind, intptr_t): Assertion `pid > && "pid

I have a pointer to a basic block and am iterating thru its predecessor blocks. I want to get a pointer to the predecessor block. How do I do it. I am using following code and it given compile time errors. error: cannot convert 'llvm::const_pred_iterator' to 'const llvm::BasicBlock*' in initialization const BasicBlock *b = PH->getParent(); // process all pred block

Nicolai, My plan is to remove getNumElements() as soon as possible. Hopefully within the next few weeks. I just made a patch on my machine that marks it deprecated, and it generates a ton of warnings. Given that some build bots build with -Werror, I don't think we can mark it deprecated unless all the usages are first removed. It occurs to me now that it might be good to mark it

Hi, I just wanted to give an update on the progress of this work. This morning I merged a patch to add the new vector types. I have added a FixedVectorType, as proposed below. I also added a ScalableVectorType. I found during my work that it is useful to be able to query isa<ScalableVectorType>(Ty). Additionally, I was concerned that it would become commonplace to take

I have written a new pass, it compiles ok but crashes when i run it with error (llvm::Pass::Pass(llvm::PassKind, intptr_t): Assertion `pid && "pid cannot be 0"' failed.). The pass is : using namespace llvm; namespace { struct Dfl : public FunctionPass { static char ID; Dfl() : FunctionPass(ID) { } virtual bool runOnFunction(Function &F) { bool

Hi John, I’d like to address some points in your message. > Practically speaking, this is going to break every out-of-tree frontend, backend, or optimization pass that supports SIMD types. My understanding is that the policy in LLVM development is that we do not let considerations for downstream and out-of-tree codebases affect the pace of development. The C++ API is explicitly unstable.

Hi, I was playing with the Constant::getAllOnesValue() method and found that it doesn't handlesPointerTypes correctly. When receiving a "i32*" argument, it was returning with some big integer vector, such as <12113216 x i32>. When you call this method passing a PointerType, the following code is executed: 00152 VectorType *VTy = cast<VectorType>(Ty);00153 return

Hi, See fuller extract below. I am curious about the for loop. for (unsigned i = 1, e = CA->getNumElements(); i != e; ++i) { What happens when CA->getNumElements() is zero ? Infinite loop???? Wouldn't the following be better. i.e. safer: for (unsigned i = 1; i < CA->getNumElements(); i++) { Kind Regards James At about line 1429: Type *ETy =

Hi, I am helping with the effort to implement scalable vectors in the codebase in order to add support for generating SVE code in the Arm backend. I would like to propose a refactor of the Type class hierarchy in order to eliminate issues related to the misuse of SequentialType::getNumElements(). I would like to introduce a new class FixedVectorType that inherits from