search for: visitloadinst

...uction type, and pass some parameters based on the instruction type. Then I will link the output to some C file that implements those functions. Things were going well until I started trying to make function calls with a pointer as a parameter. For example, I would like to do something like: void visitLoadInst(LoadInst &I) { Value *P; P = I.getPointerOperand(); CallInst::Create(load_fcall, P, "", &I); } Where load_fcall is build using a call to Module::getOrInsertFunction as in the example here: http://wiki.llvm.org/HowTo:_Insert_a_function_call My question is, what do I pass...

...ad/store operations in LLVM IR. And I find the LLVM IR generated with flag -o3 is much more efficient than -o0, so I try to instrument on these optimized LLVM IR, but, some load operations are changed to Phi loads. Then, I try the -reg2mem flag to remove these phi nodes. The problems are: 1) I use visitLoadInst to collect these load operations, and it seems I cannot reach these loads that are generated by reg2mem? What is the reason? 2) Is there any way to compile with -O3 but not generate phi nodes ? -- Best Regards! Eric Lew -------------- next part -------------- An HTML attachment was scrubbed... U...

...] Forcing the Interpreter segfaults I have build LLVM in debug mode. Here are the informations of the segfault : memcpy() at 0x7ffff6f6581e LoadIntFromMemory() at ExecutionEngine.cpp:887 0xb3c297 llvm::ExecutionEngine::LoadValueFromMemory() at ExecutionEngine.cpp:915 0xb3c3f9 llvm::Interpreter::visitLoadInst() at Execution.cpp:812 0xa1f855 llvm::InstVisitor<llvm::Interpreter, void>::visitLoad() at 0xa28357 llvm::InstVisitor<llvm::Interpreter, void>::visit() at 0xa26b4e llvm::Interpreter::run() at Execution.cpp:1,328 0xa235ff llvm::Interpreter::runFunction() at Interpreter.cpp:95 0xa166fa...

...r the meaning of constant null pointer in LLVM IR. Can the optimizer assume that dereferencing a null pointer is always unreachable? Or is it only the case for address space 0? Is it ok to have null pointer be a valid pointer for an address space other than 0? In InstCombine pass in InstCombiner::visitLoadInst(LoadInst &LI) I see that we replace load of null pointer by unreachable only for address space 0. But there is also code doing the following transformation for all the address spaces: // load (select (cond, null, P)) -> load P if(isa<ConstantPointerNull>(SI->getOperand(1...

...LVM IR. And I find the LLVM > IR generated with flag -o3 is much more efficient than -o0, so I try to > instrument on these optimized LLVM IR, but, some load operations are changed > to Phi loads. Then, I try the -reg2mem flag to remove these phi nodes. > The problems are: > 1) I use visitLoadInst to collect these load operations, and it seems I > cannot reach these loads that are generated by reg2mem? What is the reason? Clang doesn't generate optimized IR - so if your instrumentation is in Clang's IRGen (clang/lib/CodeGen) it won't see these. Clang generates the unoptimized...

...re the informations of the > > segfault : memcpy() at 0x7ffff6f6581e > > LoadIntFromMemory() at ExecutionEngine.cpp:887 0xb3c297 > > llvm::ExecutionEngine::LoadValueFromMemory() at ExecutionEngine.cpp:915 > > 0xb3c3f9 > > llvm::Interpreter::visitLoadInst() at Execution.cpp:812 0xa1f855 > > llvm::InstVisitor<llvm::Interpreter, void>::visitLoad() at 0xa28357 > > llvm::InstVisitor<llvm::Interpreter, void>::visit() at 0xa26b4e > > llvm::Interpreter::run() at Execution.cpp:1,328 0xa235ff > > ll...

...eachable? Or is it only the case for address space 0? Is it ok to > have null pointer be a valid pointer for an address space other than > 0? Correct, it is valid to have a null pointer dereference in address spaces other than 0. > > > > In InstCombine pass in InstCombiner::visitLoadInst(LoadInst &LI) I see > that we replace load of null pointer by unreachable only for address > space 0. But there is also code doing the following transformation for > all the address spaces: > > // load (select (cond, null, P)) -> load P > > if(isa<ConstantPointer...

...ssa values. It's not the same thing. On Tue, Apr 21, 2015 at 10:14 PM, Eric Lu <eirc.lew at gmail.com> wrote: > By the way. When I remove these phi nodes with -reg2mem, some new load > operations will be inserted, but when I try cache load operations with: > visitFunction > visitLoadInst > It seems we can't see these new load operations. > > On Wed, Apr 22, 2015 at 1:10 PM, Eric Lu <eirc.lew at gmail.com> wrote: >> >> Hi, Daniel >> >> I want to profile load/store operations, in order to reduce the overhead >> of profiling, I try to i...

Hi, Daniel I want to profile load/store operations, in order to reduce the overhead of profiling, I try to instrument the optimized llvm ir, which has phi nodes. BTW, when the value of some load/store operations may have multi-source, then the load will be translated into phi nodes, and all phi nodes are placed in the front of BB. Sometimes, the position is not where the load happens, is there

On Wed, May 20, 2009 at 7:31 PM, Scott Ricketts <sricketts at maxentric.com> wrote: > Where load_fcall is build using a call to Module::getOrInsertFunction > as in the example here: > > http://wiki.llvm.org/HowTo:_Insert_a_function_call > > My question is, what do I pass as the argument type for P above? The > following seems to work, as long as there are no floating

I'm using LLVM 3.3 Release. From the Class Reference Page. CallInst has a member function : static CallInst * Create (Value *Func, ArrayRef< Value * > Args, const Twine &NameStr="", Instruction *InsertBefore=0) This is what I want to use! the default name is "" and I also use that . Thanks! ----- Kind Regards! -JinHuang -- View this message in context:

Thanks Joshua and Michael, Just to to clarify, I'm experimenting with the Interpreter class and observing the instructions that are executed by it. Just for becoming more confident with LLVM in general I'd like for each instruction to access to the various parts of it. In this instance I would like to access to the %Name that is shown in the textual representation. When I call

...tParent()->getParent(); llvm::LLVMContext& ctx = Fn->getContext(); llvm::IRBuilder<> builder(ctx); FailBB = llvm::BasicBlock::Create(ctx, "FailBlock", Fn); llvm::ReturnInst::Create(Fn->getContext(), FailBB); return FailBB; } void visitLoadInst(llvm::LoadInst & LI) { } void visitStoreInst(llvm::StoreInst & SI) { llvm::Value * Addr = SI.getOperand(1); llvm::PointerType* PTy = llvm::cast<llvm::PointerType>(Addr->getType()); llvm::Type * ElTy = PTy -> getElementType(); if (!ElTy->isPointerTy...

...llvm::IRBuilder<> builder(ctx); You don't seem to ever use this builder? > > FailBB = llvm::BasicBlock::Create(ctx,"FailBlock", Fn); > llvm::ReturnInst::Create(Fn->getContext(), FailBB); > return FailBB; > > } > void visitLoadInst(llvm::LoadInst& LI) { > } > > void visitStoreInst(llvm::StoreInst& SI) { > llvm::Value * Addr = SI.getOperand(1); > llvm::PointerType* PTy = llvm::cast<llvm::PointerType>(Addr->getType()); > llvm::Type * ElTy = PTy -> getElementTyp...

> On Aug 19, 2014, at 1:32 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > >>> * Nobs for which there is not a single right answer for all users. >>> There are very few of these currently and we expect it to remain like >>> that. These should not use cl::opt or static storage at all. They >>> should be an option passed to the