search for: visitintrinsiccall

...gettype(a), &a); bpf_output(gettype(b), &b); return 0; } BPF backend can't (and needn't) tell the difference between local variables a and b in theory. In LLVM implementation, it filters type information out using ComputeValueVTs(). Please have a look at SelectionDAGBuilder::visitIntrinsicCall in lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp and SelectionDAGBuilder::visitTargetIntrinsic in the same file. in visitTargetIntrinsic, ComputeValueVTs acts as a barrier which strips type information out from CallInst ("I"), and leave SDValue and SDVTList ("Ops" and "V...

Hi, If I define a intrinsic function with pointer-typed parameter, for example, def llvm_foo_ptr_ty : LLVMPointerType<llvm_i16_ty>; def int_foo_get : Intrinsic<[llvm_foo_ptr_ty], [llvm_foo_ptr_ty, llvm_i32_ty], [IntrReadArgMem]>; How to lower it for the backend? I'm not sure what kind of register (i16 or i32 or i32) is needed in this case? If the parameter is

Hi there lowering experts, Can the llvm.mem* intrinsics ever turn into a library call? Or do they invariably turn into inline code? This comes up because there was a patch to StackProtector to use CaptureTracking instead of a home-grown analysis, which changes the treatment of calls to intrinsics. (The old code treated them as normal calls, the new code decides intrinsics can never capture.)

.../lib/Support/Unix/Signals.inc:380:0 #2 0x00000000815eb33e llvm::sys::RunSignalHandlers () /home/suganuma/tools/llvm_new/llvm/lib/Support/Signals.cpp:44:0 ... #7 0x0000000081577202 /home/suganuma/tools/llvm_new/llvm/lib/Support/ErrorHandling.cpp:117:0 #8 0x000000008139792a llvm::SelectionDAGBuilder::visitIntrinsicCall (llvm::CallInst const&, unsigned int) /home/suganuma/tools/llvm_new/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:5247:0 #9 0x000000008139b11c llvm::SelectionDAGBuilder::visitCall(llvm::CallInst const&) /home/suganuma/tools/llvm_new/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder....

2010/1/22 Garrison Venn <gvenn.cfe.dev at gmail.com> > Yes. The issue here, as you pointed out, is that your personality function > is not called at all. > Even if you did nothing in the personality function, associated with the > setup caused by > llvm.eh.selector, but returned _URC_CONTINUE_UNWIND (8), it should still be > called. > Your results are acting like either

...llvm-src/include/llvm/Support/Casting.h, line 232. With this stack (I only give the relevant part): frame #5: 0x000000010092ed44 libjvm.dylib`llvm::SelectionDAGBuilder::visitPatchpoint() + 3780 at SelectionDAGNodes.h:610 frame #6: 0x000000010091f511 libjvm.dylib`llvm::SelectionDAGBuilder::visitIntrinsicCall(this=0x0000000106ff4d20, I=0x0000000106fea460) + 10961 at SelectionDAGBuilder.cpp:5349 frame #7: 0x0000000100904c4a libjvm.dylib`llvm::SelectionDAGBuilder::visitCall(this=0x0000000106ff4d20, I=0x0000000106fea460) + 234 at SelectionDAGBuilder.cpp:5870 frame #8: 0x00000001008fc9ea libjvm.dyli...

...t; line 232. > > With this stack (I only give the relevant part): > > frame #5: 0x000000010092ed44 > libjvm.dylib`llvm::SelectionDAGBuilder::visitPatchpoint() + 3780 at > SelectionDAGNodes.h:610 > frame #6: 0x000000010091f511 > libjvm.dylib`llvm::SelectionDAGBuilder::visitIntrinsicCall(this=0x0000000106ff4d20, > I=0x0000000106fea460) + 10961 at SelectionDAGBuilder.cpp:5349 > frame #7: 0x0000000100904c4a > libjvm.dylib`llvm::SelectionDAGBuilder::visitCall(this=0x0000000106ff4d20, > I=0x0000000106fea460) + 234 at SelectionDAGBuilder.cpp:5870 > frame #8: 0x00000...

...t; return 0; >> } >> >> BPF backend can't (and needn't) tell the difference between local >> variables a and b in theory. In LLVM implementation, it filters type >> information out using ComputeValueVTs(). Please have a look at >> SelectionDAGBuilder::visitIntrinsicCall in >> lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp and >> SelectionDAGBuilder::visitTargetIntrinsic in the same file. in >> visitTargetIntrinsic, ComputeValueVTs acts as a barrier which strips >> type information out from CallInst ("I"), and leave SDValue and S...

...generated debug information, and the value of the variable c is still incorrectly reported to be 2 when on the return statement. So my question is whether: - The above addition to the IR is the correct thing to do [but if so then there is possibly a further issue in SelectionDAGBuilder::visitIntrinsicCall()'s handling of this additional line (where it is currently being discarded)] - Some other @lldm.dbg.value entry should be produced to generate the correct debug information. Keith -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.o...

...think I have found the problem to why the debug information is getting destroyed. The problem is in SelectionDAG and how it interacts with the SDDbgValue nodes and custom SDNodes. When the dbg_value intrinsic is encountered, it adds the debug value to a specific SD Node in SelectionDAGBuilder.cpp::visitIntrinsicCall(). In one of my cases, it is vector_extract_elt. During ISelLowering, the vector_extract_elt instruction is lowered to a custom backend SDNode and all of the operands are transferred over. The SDNode that stored vector_extract_elt is then deleted as it has no more uses. This then invalidates the d...

...line 232. > > With this stack (I only give the relevant part): > > frame #5: 0x000000010092ed44 > libjvm.dylib`llvm::SelectionDAGBuilder::visitPatchpoint() + 3780 at > SelectionDAGNodes.h:610 > frame #6: 0x000000010091f511 > > libjvm.dylib`llvm::SelectionDAGBuilder::visitIntrinsicCall(this=0x0000000106ff4d20, > I=0x0000000106fea460) + 10961 at SelectionDAGBuilder.cpp:5349 > frame #7: 0x0000000100904c4a > libjvm.dylib`llvm::SelectionDAGBuilder::visitCall(this=0x0000000106ff4d20, > I=0x0000000106fea460) + 234 at SelectionDAGBuilder.cpp:5870 > frame #8: 0x00000...

...))); The problem I'm facing is that for some reason, my following line inside X86TargetLowering::LowerOperation is never getting called: case ISD::SETRETURNADDR: return LowerSETRETURNADDR(Op, DAG); This is despite the fact that I can confirm the following line inside SelectionDAGBuilder::visitIntrinsicCall *is* getting called: case Intrinsic::setreturnaddress: setValue(&I, DAG.getNode(ISD::SETRETURNADDR, sdl, TLI->getPointerTy(), getValue(I.getArgOperand(0)), getValue(I.getArgOperand(1)))); return 0; My best guess is that my co...

Yes. The issue here, as you pointed out, is that your personality function is not called at all. Even if you did nothing in the personality function, associated with the setup caused by llvm.eh.selector, but returned _URC_CONTINUE_UNWIND (8), it should still be called. Your results are acting like either dwarf exception header info is not emitted (llvm::DwarfExceptionHandling = true; not executed

...e found the problem to why the debug information is getting destroyed. The problem is in SelectionDAG and how it interacts with the SDDbgValue nodes and custom SDNodes. > > When the dbg_value intrinsic is encountered, it adds the debug value to a specific SD Node in SelectionDAGBuilder.cpp::visitIntrinsicCall(). In one of my cases, it is vector_extract_elt. > > During ISelLowering, the vector_extract_elt instruction is lowered to a custom backend SDNode and all of the operands are transferred over. The SDNode that stored vector_extract_elt is then deleted as it has no more uses. This then invali...

...dd for the specific target the one that > takes part in generating the target specific code (native) from the > llvm bytecode? There are two parts to this. First, you must lower the intrinsic from its IR form (a Function*) into a SelectionDAG node. This is done in SelectionDAGISel.cpp in the visitIntrinsicCall method. You might need to change DAGCombiner.cpp and LegalizeDAG.cpp depending on the intrinsic and its lowering. The second part is to modify the targets or generic code gen to handle the lowered intrinsic call. This part is target specific. > 3. Can I introduce an intrinsic that is actually...

...of the variable c is still > incorrectly reported to be 2 when on the return statement. > > > > So my question is whether: > > - The above addition to the IR is the correct thing to do [but > if so then there is possibly a further issue in > SelectionDAGBuilder::visitIntrinsicCall()’s handling of this additional > line (where it is currently being discarded)] > > - Some other @lldm.dbg.value entry should be produced to > generate the correct debug information. > > > > Keith > _______________________________________________ > LLVM Develo...

Hi, I want to implement a new intrinsic in llvm that will denote a parallel section within a function. I followed the documentation for extending llvm (http://llvm.org/docs/ExtendingLLVM.html) but there is something about the working mechanism that is not clear for me. 1. Why do we have to add support for the C backend? Is this only necessary to transform the llvm assembly (bytecode) into C code

...think I have found the problem to why the debug information is getting destroyed. The problem is in SelectionDAG and how it interacts with the SDDbgValue nodes and custom SDNodes. When the dbg_value intrinsic is encountered, it adds the debug value to a specific SD Node in SelectionDAGBuilder.cpp::visitIntrinsicCall(). In one of my cases, it is vector_extract_elt. During ISelLowering, the vector_extract_elt instruction is lowered to a custom backend SDNode and all of the operands are transferred over. The SDNode that stored vector_extract_elt is then deleted as it has no more uses. This then invalidates the d...

...vm-gcc's any more, but it will map to dragonegg's (i.e. GCC's); since llvm-gcc is deprecated I think that it is OK. > --- a/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp > +++ b/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp > @@ -4947,12 +4947,16 @@ SelectionDAGBuilder::visitIntrinsicCall(const CallInst &I, unsigned Intrinsic) { > Ops[4] = DAG.getSrcValue(I.getArgOperand(0)); > Ops[5] = DAG.getSrcValue(F); > > - Res = DAG.getNode(ISD::TRAMPOLINE, dl, > - DAG.getVTList(TLI.getPointerTy(), MVT::Other), > - Op...

John, Mem2reg actually modifies debug information in a way that at least suggests it's trying to maintain debugability. Specifically, it changes llvm.dbg.declare() calls (appropriate for variables that permanently reside in a single place) to llvm.dbg.value() calls (specifying that at this instant, this variable is in this register). In fact, the .bc after inlining and mem2reg