search for: getargoperands

Hi everyone: The code I am analyzing is : int main() { int i = 0; printf("hello world!"); printf( "%d" , i ); } I want to get each place where printf is called, and the argument used during that call. so I write llvm pass code like: void Myfunction( Function & F){ for( Function::iterator b = F.begin() , be = F.end() ;

Hi, Working on private backend, based on llvm-3.7 Inside lib/Transforms/InstCombine/InstCombineCompares.cpp there is attempt to optimize fabs: if (F->getIntrinsicID() == Intrinsic::fabs || ... switch (I.getPredicate()) { ... case FCmpInst::FCMP_OGT: return new FCmpInst(FCmpInst::FCMP_ONE, CI->getArgOperand(0), RHSC); But CI->getArgOperand(0)

Thanks a lot! I finally fix my problem. My code is like this: //CallInst* pCall pCall is a printf called in my situation if( ConstantExpr * pCE = dyn_cast<ConstantExpr>( pCall->getArgOperand(0))){ if( GlobalVariable * pGV = dyn_cast<GlobalVariable>( pCE->getOperand(0))){ if( ConstantArray * pCA = dyn_cast<ConstantArray>(

I'm working on the code to handle GC tracing of "intermediate values" (as described in the GC doc), and I've run into a weird problem. (Note, this has nothing to do with the patch I have proposed, this error occurs with regular old pointer-allocas.) The exception I am getting occurs in this code here in SelectionDAGBuilder.cpp: *case* *Intrinsic*::gcroot: *if* (GFI) {

On Wed, Aug 05, 2015 at 04:28:13PM +0800, Wangnan (F) wrote: > > It doesn't work for me at first since in my llvm there's only > llvm.bpf.load.*. > > I think llvm.bpf.store.* belone to some patches you haven't posted yet? nope. only loads have special instructions ld_abs/ld_ind which are represented by these intrinsics. stores, so far, are done via single

songlh at cs.wisc.edu wrote: > Hi everyone: > > The code I am analyzing is : > > int main() > { > int i = 0; > printf("hello world!"); > printf( "%d" , i ); > } > > > > I want to get each place where printf is called, and the argument used > during that call. > > so I write llvm

Hi Thomson, the new call to puts() is inserted right away, whereas the old call to printf() is removed a bit later in SimplifyLibCalls::runOnFunction(). If you browse the code a bit and backtrack the call stack to see what happens with the return value of PrintFOpt::OptimizeFixedFormatString(), you will stumble upon this segment in SimplifyLibCalls.cpp:1703ff.: // Try to optimize this call.

Hi Talin, I think that the framework for GC assumes llvm.gcroot to be in the first block. If it is not the case in your example, it will break these assumptions. Nicolas On Sun, Sep 26, 2010 at 1:38 AM, Talin <viridia at gmail.com> wrote: > I'm working on the code to handle GC tracing of "intermediate values" (as > described in the GC doc), and I've run into a

I'm trying to track down the problem with the assertion failure in SelectionDAGBuilder.cpp. This is the code: *case* *Intrinsic*::gcroot: *if* (GFI) { *const* Value *Alloca = I.getArgOperand(0); *const* Constant *TypeMap = cast<Constant>(I.getArgOperand(1)); * FrameIndexSDNode *FI = cast<FrameIndexSDNode>(getValue(Alloca).getNode());*

I found that LLVM optimized the IR by replacing printf with puts. I wondered which pass did this optimization? And is it common that puts is faster (and some other metric) than printf? -- Thanks Thomson -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120617/08aa6c45/attachment.html>

Hi Duncan, Thanks for pointing out my mistake. I will reword my questions. //C code int var1; //global int a, b; foo(a, b); bar(c); generates following //LLVM IR %1 = load a; %2 = load b; call foo(%1, %2) call bar(@var1) CallInst.getOperand(1).getNameStr() on foo, returns null, but on bar returns var1. Similarly, for call void @p_ptr(i64 ptrtoint (%struct.my_struct* @abc to i64)) nounwind,

The documentation of LLVM says that "The llvm.objectsize intrinsic is lowered to a constant representing the size of the object concerned". I'm attempting to lower this intrinsic function to a constant in a pass. Below is the code snippet that I wrote: for (BasicBlock::iterator i = b.begin(), ie = b.end(); (i != ie) && (block_split == false);) { IntrinsicInst *ii =

I actually need this feature quite badly in my untyped language compiler: since I support first-class functions, I've made the types of all functions a standard vararg (so I can box them). The implementation crashes when I try to read out the value of gc.result. Hints as to what might be wrong? Signed-off-by: Ramkumar Ramachandra <artagnon at gmail.com> ---

Hi all, I would like my optimization pass to change an object's address space that is created by llvm.lifetime.start intrinsic. Because I want to be able to identify them later in a codegen pass. I can get a pointer from the intrinsic using CallInst::getArgOperand() function. However, I don't know what to do with it (or if it is the pointer that I want). How can I change its address space?

Hi, I'm not sure. But in your lowered DAG the chain nodes are the first operands for you custom nodes, however for the other nodes the chain is the last operand. I seem to remember that during targetlowering the chain is the first operand and then it seems to switch over after ISelDAG, this confused me and may have something to do with the issue that you are seeing. I really don't

Hi Sanjoy, > Attached set of patches splits llvm.init.trampoline into an "init" > phase and an "adjust" phase, as discussed on the "Go on dragonegg" > thread. thanks for doing this. The patches look good, though the decomposition into individual patches is not that great (since things won't always work, in fact not even compile I think, with not all

Thank you Ahmad, I figured out that, although the type of both p(oInst) and p(nInst) were the same, I had to: for (unsigned int i = 0; i < callOInst->getNumArgOperands(); i++) { callOInst->getArgOperand(i)->mutateType(callNInst->getArgOperand(i)->getType()); } that solves the issue at the calling instruction in the main function, but now I see that *linkModules* does not work

Hi! Attached set of patches splits llvm.init.trampoline into an "init" phase and an "adjust" phase, as discussed on the "Go on dragonegg" thread. Thanks! -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Split-intrinsics-and-DAG-nodes.patch Type: text/x-diff Size: 8808 bytes Desc:

Hi, I've been having some trouble implementing a new intrinsic for LLVM and I was wondering if someone might know the answer. LLVM has an llvm.returnaddress intrinsic, but for a specific project, I need to be able to modify the return address of a function as well, so I'm implementing a new intrinsic: def int_setreturnaddress : Intrinsic<[], [llvm_i32_ty, llvm_ptr_ty], []>;

On 2/16/2016 8:44 AM, Konstantin Vladimirov via llvm-dev wrote: > > CI->getArgOperand(0) returns operand with type (double*) rather then > double, because in our ABI doubles are passed via memory. The LLVM intrinsics in the LLVM IR must conform to whatever the IR's requirements are. That means that even in the case of your backend, the arguments to the intrinsic must be doubles,