search for: src2

...or): (WARNING! Hacked-up tablegen ahead!) multiclass sse_fp_binop_bitwise_rm<bits<8> opc, string OpcodeStr, SDNode OpNode> { // Vector operation emulating scalar (fp) def FsPSrr : PSI<opc, MRMSrcReg, (outs FR32:$dst), (ins FR32:$src1, FR32: $src2), !strconcat(OpcodeStr, "ps"\t{$src2, $dst|$dst, $src2}"), [(set FR32:$dst, (!SOME_CONCAT("x86f", OpNode) FR32: $src1, FR32:$src2))]>; // Vector operation def PSrr : PSI<opc, MRMSrcReg, (outs VR128:$dst), (ins VR128:$sr...

...op, > Operand CC, Intrinsic Int, string asm, > string asm_alt, Domain d, > OpndItins itins = SSE_ALU_F32P> { > def rri : PIi8<0xC2, MRMSrcReg, > (outs RC:$dst), (ins RC:$src1, RC:$src2, CC:$cc), asm, > [(set RC:$dst, (Int RC:$src1, RC:$src2, imm:$cc))], > itins.rr, d>, > Sched<[WriteFAdd]>; > def rmi : PIi8<0xC2, MRMSrcMem, > (outs RC:$dst), (ins RC:$src1, x86memop:$src2, CC:$cc), asm, >...

Currently, instruction selection patterns are defined like this: def : Pat<(and (not GR32:$src1), GR32:$src2), (ANDN32rr GR32:$src1, GR32:$src2)>; def : Pat<(and (not GR64:$src1), GR64:$src2), (ANDN64rr GR64:$src1, GR64:$src2)>; TableGen infers the types of $src1 and $src2 from the specified register classes, and that is the only purpose of the register classes in a pa...

...($addr)", >> []>; >> >> let mayLoad = 1, neverHasSideEffects = 1 in >> -def LDrid_indexed_cPt : LDInst<(outs DoubleRegs:$dst), >> +def LDrid_indexed_cPt : LDInst2<(outs DoubleRegs:$dst), >> (ins PredRegs:$src1, IntRegs:$src2, u6_3Imm:$src3), >> "if ($src1) $dst=memd($src2+#$src3)", >> []>; >> >> let mayLoad = 1, neverHasSideEffects = 1 in >> -def LDrid_indexed_cNotPt : LDInst<(outs DoubleRegs:$dst), >> +def LDrid_indexed_cNotPt : LDInst2&...

...rm, the only difference is the size > // of r and m. > let Constraints = "$src1 = $dst" in { > - def CRC32m8 : SS42FI<0xF0, MRMSrcMem, (outs GR32:$dst), > + def CRC32r32m8 : SS42FI<0xF0, MRMSrcMem, (outs GR32:$dst), > (ins GR32:$src1, i8mem:$src2), > "crc32{b} \t{$src2, $src1|$src1, $src2}", > [(set GR32:$dst, > - (int_x86_sse42_crc32_8 GR32:$src1, > + (int_x86_sse42_crc32_32_8 GR32:$src1, > (load ad...

In BPF, an ADD instruction is defined as a 2 register instruction: 0x0f. add dst, src. dst += src In BPFInstrInfo.td this kind of ALU instruction is defined with: def _rr : ALU_RR<BPF_ALU64, Opc, (outs GPR:$dst), (ins GPR:$src2, GPR:$src), "$dst "#OpcodeStr#" $src", [(set GPR:$dst, (OpNode i64:$src2, i64:$src))]>; How does tablegen+codegen ensure that dst and src2 are the same register? I see that the assembly/disassembly string assumes this is the case. Also,...

hi, some instructions mismatch between assembler & disassembler, like below. it seems this happens with all SSECC related instructions? thanks, Jun $ echo "cmpps xmm1, xmm2, 23" | ./Release+Asserts/bin/llvm-mc -assemble -triple=x86_64 --output-asm-variant=1 -x86-asm-syntax=intel -show-encoding .text cmpps xmm1, xmm2, 23 # encoding: [0x0f,0xc2,0xca,0x17] $

....uiuc.edu, llvmdev at cs.uiuc.edu, llvmdev at cs.uiuc.edu > Sent: Thursday, March 21, 2013 1:26:25 PM > Subject: [LLVMdev] Simpler types in TableGen isel patterns > > Currently, instruction selection patterns are defined like this: > > def : Pat<(and (not GR32:$src1), GR32:$src2), > (ANDN32rr GR32:$src1, GR32:$src2)>; > def : Pat<(and (not GR64:$src1), GR64:$src2), > (ANDN64rr GR64:$src1, GR64:$src2)>; > > TableGen infers the types of $src1 and $src2 from the specified > register classes, and that is the only purpose o...

...en ahead!) > > multiclass sse_fp_binop_bitwise_rm<bits<8> opc, string OpcodeStr, > SDNode OpNode> { > // Vector operation emulating scalar (fp) > def FsPSrr : PSI<opc, MRMSrcReg, (outs FR32:$dst), (ins FR32:$src1, > FR32: > $src2), > !strconcat(OpcodeStr, "ps"\t{$src2, $dst|$dst, > $src2}"), > [(set FR32:$dst, (!SOME_CONCAT("x86f", OpNode) > FR32: > $src1, FR32:$src2))]>; > > // Vector operation > def PSrr : PSI<opc, MRMSr...

...ma3s_rm<bits<8> opc, string OpcodeStr, X86MemOperand x86memop, RegisterClass RC, ValueType OpVT, PatFrag mem_frag, SDPatternOperator OpNode = null_frag> { def r : FMA3<opc, MRMSrcReg, (outs RC:$dst), (ins RC:$src1, RC:$src2, RC:$src3), !strconcat(OpcodeStr, "\t{$src3, $src2, $dst|$dst, $src2, $src3}"), [(set RC:$dst, (OpVT (OpNode RC:$src2, RC:$src1, RC:$src3)))]>; Given that it is an FMA pattern, the OpNode can be...

Thank You. But can we use same register class for fadd as well, is this instruction correct? def VFADD : I<0x0E, MRMDestReg, (outs VRR128:$dst), (ins VRR128:$src1, VRR128:$src2),"VFADD\t{$src1, $src2, $dst|$dst, $src1, $src2}", [(set VRR128:$dst, (fadd VRR128:$src1, VRR128:$src2))]>, TA; On Tue, Jul 11, 2017 at 9:00 PM, Craig Topper <craig.topper at gmail.com> wrote: > "add" only works for integers. Floating point requires fadd. They are...

...too? I added the avx checks to the same file (in which case calling it sse3-haddsub.ll is not so great). > 4) Your tablegen modifications are totally fine, for the intrinsics just do: > > let Predicates = [HasSSE3] in { > def : Pat<(int_x86_sse3_hadd_ps (v4f32 VR128:$src1), VR128:$src2), > (HADDPSrr VR128:$src1, VR128:$src2)>; > def : Pat<(int_x86_sse3_hadd_ps (v4f32 VR128:$src1), (memop addr:$src2)), > (HADDPSrm VR128:$src1, addr:$src2)>; > ... > > and > > let Predicates = [HasAVX] in { > def : Pat<(int_x86_sse3_hadd_p...

...[llvm_i16_ty, llvm_i16_ty], [IntrNoMem]>; that I want to translate to the following instruction during instruction selection: def divm16_pseudo : MyPseudoInst< (outs aNh_0_7:$dst, aNh_0_7:$dst2), (ins aNh_0_7:$src1, aNh_0_7:$src2)>; So I've done a pattern the same way I've done for numerous other intrinsics (that returns simple types like i16/i32 etc): def : Pat<(int_phx_divm_u16 i16:$src1, i16:$src2), (divm16_pseudo $src1, $src2)>; But this doesn't work for me: anonymous_1373(src1, src2...

...w i32 %0, 1 ret i32 %sub } But finally in code generation i am getting: ldc r2, #-1 add r0, r2, r0 Should this not be doing: ldc r2 #1 sub r0 r2 r0 I have defined both my add and sub instructions: def ADD : ALUInst<0b0001, (outs GRRegs:$dst), (ins GRRegs:$src1, GRRegs:$src2), "add $src1, $src2, $dst", [(set i32:$dst, (add i32:$src1, i32:$src2))]>; def SUB : ALUInst<0b0010, (outs GRRegs:$dst), (ins GRRegs:$src1, GRRegs:$src2), "sub $src1, $src2, $dst",...

Thank You. How to do the same for add please see the following; it gives duplication error. def VADD : I<0x0E, MRMDestReg, (outs VRR128:$dst), (ins VRR128:$src1, VRR128:$src2),"VADD\t{$src1, $src2, $dst|$dst, $src1, $src2}", [(set VRR128:$dst, (add VRR128:$src1, VRR128:$src2))]>, TA; def : Pat<(add VRR128:$src1, VRR128:$src2), (VADD VRPIM128:$src1, VRPIM128:$src2)>; Where to place v32f32 to distinguish between the two? On Tue, Jul 11, 2017 at 7:55...

...[(set DSTREGCLASS:$dst, > (DSTTYPE (movlhps SRCREGCLASS:$src1, > (DSTTYPE (bitconvert > (v2f64 (scalar_to_vector > (loadf64 addr:$src2))))))))], > // rr Pat > [], > // rm Pat > [[(DSTTYPE (movlhps SRCREGCLASS:$src1, (load addr:$src2))), > (MNEMONIC SRCREGCLASS:$src1, addr:$src2)], > [(INTDSTTYPE (movlhps SRCREGCLASS:$src1, (load addr:$src2))), >...

Hello Jim thanks for the reply, For normal additions with immediates I've done the same as ARM does, basically transforming add(x, imm) nodes to sub(x, -imm) with a pattern in the .td file like this: def : Pat<(add DLDREGS:$src1, imm:$src2), (SUBIWRdK DLDREGS:$src1, (imm16_neg_XFORM imm:$src2))>; Now, the typical pattern concerning additions with global addresses looks like this: (taken from x86) def : Pat<(add GR32:$src1, (X86Wrapper tglobaladdr :$src2)), (ADD32ri GR32:$src1, tglobaladdr:$src2)>...

...opc, string OpcodeStr, X86MemOperand x86memop, > RegisterClass RC, ValueType OpVT, PatFrag mem_frag, > SDPatternOperator OpNode = null_frag> { > > def r : FMA3<opc, MRMSrcReg, (outs RC:$dst), > (ins RC:$src1, RC:$src2, RC:$src3), > !strconcat(OpcodeStr, > "\t{$src3, $src2, $dst|$dst, $src2, $src3}"), > [(set RC:$dst, > (OpVT (OpNode RC:$src2, RC:$src1, RC:$src3)))]>; > > > Given that it is a...

...hrev=162999 For the multiclass "fma4s", why is "mr" not inherited from "VEX_W" and "MemOp4" like those of "rm" or "rr" ? multiclass fma4s< > ... def mr : FMA4<opc, MRMSrcMem, (outs RC:$dst), (ins RC:$src1, x86memop:$src2, RC:$src3), !strconcat(OpcodeStr, "\t{$src3, $src2, $src1, $dst|$dst, $src1, $src2, $src3}"), [(set RC:$dst, (OpNode RC:$src1, (mem_frag addr:$src2), RC:$src3))]>; ... It seems that previous revisions for fma4 intrinsics also followed similar trend. A...

...function. R1-R4 are marked as calleesaved. From the above code I cannot see any reason why R1 & R2 are being spilled, I assume the fault lies in my tablegen definitions (relevant ones reproduced below) : let isCommutable=1 in { def ADD32rrr : M819Inst<(outs GR32:$dst),(ins GR32:$src1, GR32:$src2),"ADD.L\t{$dst,$src1 + $src2}",[(set GR32:$dst, (add GR32:$src1, GR32:$src2))]>; } def ADD32rri : M819Inst<(outs GR32:$dst),(ins GR32:$src1, i32imm:$src2),"ADD.L\t{$dst,$src1 + $src2}",[(set GR32:$dst, (add GR32:$src1, imm:$src2))]>; def SUB32rrr : M819Inst<(outs GR...