search for: intrinsic_w_chain

Hi guys, I am working on an intrinsic function, which will write to a pointer argument. So I am lowering it and think I need to catch it in lowerINTRINSIC_W_CHAIN, but somehow it always fall into INTRINSIC_WO_CHAIN category. I put [IntrReadwriteArgMem] into my Intrinsic class definition, it did not help. tried put [SDNPHasChain] into intrinsic class definition, cause errors” Element type mismatch for list”. wondering how to flag it to INTRINSIC_W_CHAI...

...2>]>, [SDNPHasChain, SDNPSideEffect]>; “ let Defs = [EFLAGS] in def XTEST : I<0x01, MRM_D6, (outs), (ins), "xtest", [(set EFLAGS, (X86xtest))]>, TB, Requires<[HasTSX]>; which CALL makes the “Intrinsic::x86_xtest” is caught under “INTRINSIC_W_CHAIN”? feel I missed something, but did not figure out. tks kevin On Jul 23, 2014, at 1:16 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Hello > > Chain operand is needed if the intrinsic is reading / writing memory. > > On Wed, Jul 23, 2014 at 8:02 PM, kewuzhan...

...On Jul 18, 2014, at 3:06 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 7/18/2014 2:00 PM, kewuzhang wrote: >> >> I am working on an intrinsic function, which will write to a pointer argument. >> So I am lowering it and think I need to catch it in lowerINTRINSIC_W_CHAIN, but somehow it always fall into INTRINSIC_WO_CHAIN category. >> >> I put [IntrReadwriteArgMem] into my Intrinsic class definition, it did not help. >> tried put [SDNPHasChain] into intrinsic class definition, cause errors” Element type mismatch for list”. >> >>...

I am currently working on DAGToDAGISel class for MIPS and am trying to figure out a way to use INTRINSIC_W_CHAIN for an intrinsic which can return a value. My intrinsic is defined as: Intrinsic<[llvm_i32_ty],[llvm_i32_ty,llvm_i32_ty,llvm_i32_ty,llvm_i32_ty],[IntrReadWriteArgMem]>; i.e. it has four arguments and one return value In DAGToDAGISel when I try to pass it with four arguments and a return re...

...t; wrote: >>>> >>>>> On 7/18/2014 2:00 PM, kewuzhang wrote: >>>>>> >>>>>> I am working on an intrinsic function, which will write to a pointer argument. >>>>>> So I am lowering it and think I need to catch it in lowerINTRINSIC_W_CHAIN, but somehow it always fall into INTRINSIC_WO_CHAIN category. >>>>>> >>>>>> I put [IntrReadwriteArgMem] into my Intrinsic class definition, it did not help. >>>>>> tried put [SDNPHasChain] into intrinsic class definition, cause errors” Eleme...

...rzyszek <kparzysz at codeaurora.org> wrote: >> >>> On 7/18/2014 2:00 PM, kewuzhang wrote: >>>> >>>> I am working on an intrinsic function, which will write to a pointer argument. >>>> So I am lowering it and think I need to catch it in lowerINTRINSIC_W_CHAIN, but somehow it always fall into INTRINSIC_WO_CHAIN category. >>>> >>>> I put [IntrReadwriteArgMem] into my Intrinsic class definition, it did not help. >>>> tried put [SDNPHasChain] into intrinsic class definition, cause errors” Element type mismatch for lis...

Hi guys, In X86ISelLowering.cpp I saw” ... case Intrinsic::x86_rdrand_16: case Intrinsic::x86_rdrand_32: …. case Intrinsic::x86_avx512_gather_qpd_512: case Intrinsic::x86_avx512_gather_qps_512: .. “ those intrinsics are handled by “LowerINTRINSIC_W_CHAIN”. How the “INTRINSIC_W_CHAIN” opCode is set instead of “INTRINSIC_WO_CHAIN”? tks Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140723/f79d901c/attachment.html>

Drear there: The problem I have is to lower an intrinsic function like this ” float @llvm.write.arg(flaot %src, float* %dst) “ I am lowering it with INTRINSIC_W_CHAIN, so the return value and the value to write to dst are generated with some operations using src: " // it is the frame index node corresponding to input pointer SDvalue frindex = Op.getoperand(3); … SDValue returnValue = DAG.getNode(myNode1, DL, VT….); SDValue dstValue = DAG.getNode(myNode...

...in SelectionDAG visitTargetIntrinsic We ran into a problem where specifying IntrNoMem was causing our instruction selection to fail with target specific intrinsics. After looking into the code and ISel debug it looks like tablegen and SelectionDAG are using different criteria to generate code for intrinsic_w_chain vs intrinsic_wo_chain. In CodeGenDAGPatterns.cpp, tablegen decides based on whether IntrNoMem is set or not. However with SelectionDAG, whether to use a chain or not is determined by the call site attributes and not by the intrinsic. So, we can get the situation where the call site has a differen...

It seems that Tablegen is generating intrinsic ID's off by in DAGISel.inc In DAGISel.inc, I have the following pattern: int64_t CN1 = Tmp0->getZExtValue(); // Pattern: (intrinsic_w_chain:f32 103:iPTR, GPRF32:f32:$src0, GPRF32:f32:$src1, GPRF32:f32:$src2) // Emits: (MACRO_FMA_f32:f32 GPRF32:f32:$src0, GPRF32:f32:$src1, GPRF32:f32:$src2) // Pattern complexity = 8 cost = 1 size = 0 if (CN1 == INT64_C(103)) { SDValue N2 = N.getOperand(2); SDValue N3 = N.g...

...def int_opencl_math_fdistance_fast : Intrinsic<[llvm_float_ty], [llvm_anyfloat_ty, LLVMMatchType<0>]>; The problem comes when I try to use the intrinsic. It gives me the following error: GPRV2F32:f32:$src1 MACRO_DISTANCE_FAST_v2f32: (set GPRF32:f32:$dst, (intrinsic_w_chain:f32 84:iPTR, GPRV2F32:v2f32:$src0, GPRV2F32:f32:$src1)) TableGen.exe: In MACRO_DISTANCE_FAST_v2f32: Type inference contradiction found in node! I'm using the following test td file. This is generated with putting it in include and running the command Tablegen.exe -dag-isel -I. test.td The p...

...;1, i32>, SDTCisVT<2, i32> ]>; Node: def atom_g_add_noret : SDNode<"AMDILISD::ATOM_G_ADD_NORET", SDTIL_BinAtomNoRet, [SDNPHasChain]>; Pattern: def ATOM_G_ADD_NORET : BinAtomNoRet<IL_OP_UAV_ADD, "_id($id)", atom_g_add_noret>; I am Lowering INTRINSIC_W_CHAIN to lower from @llvm.amdil.atomic.add.gi32.noret to the correct instruction with the following code sequence. LowerINTRINSIC_W_CHAIN(...) { ... case AMDILIntrinsic::AMDIL_atomic_add_gu32_noret: IntNo = AMDILISD::ATOM_G_ADD_NORET; break; ... SDValue Ops[6]; SDValue chain = Op.getOpe...

I'm trying to 'lower' an operation that needs to create a node in the SD that is an intrinsic call.... what is the best way to do this? I see in the DAGBuilder it calls 'setValue' which adds to the map NodeMap[V] where V is the key and the passed in SDValue is the value but I'm not sure this is a good way to do it since these are local to SelectionDAGBuilder and the

...e_fast   : Intrinsic<[llvm_float_ty], >                           [llvm_anyfloat_ty, LLVMMatchType<0>]>; > > The problem comes when I try to use the intrinsic. It gives me the > following error: > GPRV2F32:f32:$src1 MACRO_DISTANCE_FAST_v2f32:   (set GPRF32:f32:$dst, > (intrinsic_w_chain:f32 84:iPTR, GPRV2F32:v2f32:$src0, > GPRV2F32:f32:$src1)) > TableGen.exe: In MACRO_DISTANCE_FAST_v2f32: Type inference contradiction > found in node! > > I'm using the following test td file. > > This is generated with putting it in include and running the command > Tabl...

...get = 1 in your intrinsics file? On Apr 14, 2009, at 6:34 PM, Villmow, Micah wrote: > It seems that Tablegen is generating intrinsic ID’s off by in > DAGISel.inc > > In DAGISel.inc, I have the following pattern: > int64_t CN1 = Tmp0->getZExtValue(); > > // Pattern: (intrinsic_w_chain:f32 103:iPTR, GPRF32:f32:$src0, > GPRF32:f32:$src1, GPRF32:f32:$src2) > // Emits: (MACRO_FMA_f32:f32 GPRF32:f32:$src0, GPRF32:f32:$src1, > GPRF32:f32:$src2) > // Pattern complexity = 8 cost = 1 size = 0 > if (CN1 == INT64_C(103)) { > SDValue N2 = N.getOpera...

Oops. That was premature. I think your original question was on the right track. TableGen distinguishes between known and "overloaded" types (like "llvm_anyfloat_ty" in your example). The overloaded types are numbered separately, and the argument to LLVMMatchType is an index into these overloaded types, ignoring the known types. So, in your case, the first

...onDAG visitTargetIntrinsic > > We ran into a problem where specifying IntrNoMem was causing our instruction selection to fail with target specific intrinsics. After looking into the code and ISel debug it looks like tablegen and SelectionDAG are using different criteria to generate code for intrinsic_w_chain vs intrinsic_wo_chain. > > In CodeGenDAGPatterns.cpp, tablegen decides based on whether IntrNoMem is set or not. However with SelectionDAG, whether to use a chain or not is determined by the call site attributes and not by the intrinsic. > > So, we can get the situation where the ca...

...e_fast : Intrinsic<[llvm_float_ty], > [llvm_anyfloat_ty, LLVMMatchType<0>]>; > > The problem comes when I try to use the intrinsic. It gives me the > following error: > GPRV2F32:f32:$src1 MACRO_DISTANCE_FAST_v2f32: (set GPRF32:f32:$dst, > (intrinsic_w_chain:f32 84:iPTR, GPRV2F32:v2f32:$src0, > GPRV2F32:f32:$src1)) > TableGen.exe: In MACRO_DISTANCE_FAST_v2f32: Type inference > contradiction > found in node! Your "$src1" is f32 instead of v2f32. I've run into some problems like this before and concluded that TableGen'...

...gt; Node: > def atom_g_add_noret : SDNode<"AMDILISD::ATOM_G_ADD_NORET", SDTIL_BinAtomNoRet, [SDNPHasChain]>; > > Pattern: > def ATOM_G_ADD_NORET : BinAtomNoRet<IL_OP_UAV_ADD, > "_id($id)", atom_g_add_noret>; > > > I am Lowering INTRINSIC_W_CHAIN to lower from @llvm.amdil.atomic.add.gi32.noret to the correct instruction with the following code sequence. > > LowerINTRINSIC_W_CHAIN(…) > { > … > case AMDILIntrinsic::AMDIL_atomic_add_gu32_noret: > IntNo = AMDILISD::ATOM_G_ADD_NORET; break; > … > SDValue...

...t : SDNode<"AMDILISD::ATOM_G_ADD_NORET", > SDTIL_BinAtomNoRet, [SDNPHasChain]>; > > > > Pattern: > > def ATOM_G_ADD_NORET : BinAtomNoRet<IL_OP_UAV_ADD, > > "_id($id)", atom_g_add_noret>; > > > > > > I am Lowering INTRINSIC_W_CHAIN to lower from > @llvm.amdil.atomic.add.gi32.noret to the correct instruction with the > following code sequence. > > > > LowerINTRINSIC_W_CHAIN(...) > > { > > ... > > case AMDILIntrinsic::AMDIL_atomic_add_gu32_noret: > > IntNo = AMDILISD::ATOM_...