search for: fr32

...E_CONCAT with an appropriate operator): (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, MRMSrcRe...

...t;$src1 = $dst" in { multiclass basic_sse1_fp_binop_rm<bits<8> opc, string OpcodeStr, SDNode OpNode, Intrinsic F32Int, bit Commutable = 0> { // Scalar operation, reg+reg. def SSrr : SSI<opc, MRMSrcReg, (outs FR32:$dst), (ins FR32:$src1, FR32:$src2), !strconcat(OpcodeStr, "ss\t{$src2, $dst|$dst, $src2}"), [(set FR32:$dst, (OpNode FR32:$src1, FR32:$src2))]> { let isCommutable = Commutable; } // Scalar operation, reg+mem. def SSrm : SSI<opc, MRMSrcMe...

Bill, Sorry if I wasn't clear enough. I wasn't referring to multiclass's that define other classes, but with using patterns inside of a multiclass to reduce redundant code. For example: multiclass IntSubtract<SDNode node> { def _i8 : Pat<(sub GPRI8:$src0, GPRI8:$src1), (ADD_i8 GPRI8:$src0, (NEGATE_i8 GPRI8:$src1))>; def _i32 : Pat<(sub

...llvm_v2f64_ty, llvm_v2f64_ty, llvm_v2f64_ty], [IntrNoMem, Commutative]>; Untested multiclass! Look for SOME_CONCAT. multiclass myintrinsics<bits<8> opc, string OpcodeStr, Intrinsic Intr> { // Scalar intrinsics def SSrr_Int SSI<opc, MRMSrcReg, (outs FR32:$dst), (ins FR32:$src1, FR32: $src2), !strconcat(OpcodeStr, "ss\t{$src2, $dst|$dst, $src2}"), [(set FR32:$dst, (SOME_CONCAT(Intr, _ss) FR32:$src1, FR32: $src2))]> { def SDrr_Int SSI<opc, MRMSrcReg, (outs FR64:$dst), (ins FR64:$src1, FR64: $src2),...

...hris > > > (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))]>; > > // Vec...

Hello, I have studied register allocation in theoretical aspects and exploring the same in the implementation level. I need a minimal testcase for register spilling to analyze spilling procedure in llvm. I tried with a testcase taking 20 variables but all the 20 variables are getting stored in the stack using %rbp. Maybe my live variable analysis is wrong. Please help me with a minimal testcase

Hi, I noticed a bunch of psuedo instructions used for creation of constants without generating loads. e.g. pxor xmm0, xmm0 Here is an example of what i am referring to snipped from X86InstrSSE.td: def FsFLD0SS : I<0xEF, MRMInitReg, (outs FR32:$dst), (ins), "", [(set FR32:$dst, fp32imm0)]>, Requires<[HasSSE1]>, TB, OpSize; My question is why was there a need to define such a pseudo instruction? Wouldn't it be cleaner to use a def: Pat<> which selects: pxor $dst, $dst from:...

Hi all, I think I found a bug in LLVM 3.0: When compiling for a target without SSE2 support, there were some 128-bit PXOR instructions in the generated code. I traced it down to the following definition in X86InstrSSE.td: def FsFLD0SS : I<0xEF, MRMInitReg, (outs FR32:$dst), (ins), "", [(set FR32:$dst, fp32imm0)]>, Requires<[HasSSE1]>, TB, OpSize; I tried replacing the HasSSE1 with a HasSSE2 but that didn't do the trick. I noticed that TOT has a different definition and I tried substituting that a...

...t;$src1 = $dst" in { multiclass basic_sse1_fp_binop_rm<bits<8> opc, string OpcodeStr, SDNode OpNode, Intrinsic F32Int, bit Commutable = 0> { // Scalar operation, reg+reg. def SSrr : SSI<opc, MRMSrcReg, (outs FR32:$dst), (ins FR32:$src1, FR32:$src2), !strconcat(OpcodeStr, "ss\t{$src2, $dst|$dst, $src2}"), [(set FR32:$dst, (OpNode FR32:$src1, FR32:$src2))]> { let isCommutable = Commutable; } // Scalar operation, reg+mem....

..., it would be possible to replace the virtual register with a GR32 register. It's not impossible to do, but it doesn't come up a lot. When not using sub-registers, the optimization does exist. For example, if you have a VR128 virtual register, but all the instructions using it only require FR32, MRI->recomputeRegClass() will figure it out, and downgrade to FR32. It gets permission to do this because X86RegisterInfo::getLargestLegalSuperClass(VR128) returns FR32. /jakob

...> > I think I found a bug in LLVM 3.0: When compiling for a target without > SSE2 support, there were some 128-bit PXOR instructions in the generated > code. > > I traced it down to the following definition in X86InstrSSE.td: > >   def FsFLD0SS : I<0xEF, MRMInitReg, (outs FR32:$dst), (ins), "", >                    [(set FR32:$dst, fp32imm0)]>, >                    Requires<[HasSSE1]>, TB, OpSize; > > I tried replacing the HasSSE1 with a HasSSE2 but that didn't do the > trick. I noticed that TOT has a different definition and I tried...

Jakob Stoklund Olesen <jolesen at apple.com> writes: >> What happens if the result of the above pattern using COPY_TO_REGCLASS >> is spilled? Will we get a 64-bit store or a 128-bit store? > > This behavior isn't affected by the change. FR64 registers are spilled > with 64-bit stores, and VR128 registers are spilled with 128-bit > stores. > > When the

Hi, I'm looking at scalar and packed instructions in X86. The instruction VCOMISS is scalar. May I remove SSEPackedSingle/SSEPackedDouble domain from it? defm VUCOMISS : sse12_ord_cmp<0x2E, FR32, X86cmp, f32, f32mem, loadf32, "ucomiss", SSEPackedSingle>, TB, VEX, VEX_LIG; defm VUCOMISD : sse12_ord_cmp<0x2E, FR64, X86cmp, f64, f64mem, loadf64, "ucomisd", SSEPackedDouble>, TB, OpSize, VEX,...

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Tom Stellard > Sent: 19 September 2014 01:36 > To: Sanjay Patel > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] predicates vs. requirements [TableGen, > X86InstrInfo.td] > > On Thu, Sep 18, 2014 at 03:25:07PM -0600, Sanjay Patel wrote: >

...may not be able to eliminate this movss with coalescing the >> src and >> // dest register classes are different. We really want to write this >> pattern >> // like this: >> // def : Pat<(f32 (vector_extract (v4f32 VR128:$src), (iPTR 0))), >> // (f32 FR32:$src)>; >> >> (this is actually a very useful and important pattern, I wish it was >> available!) > > Right. It would be nice to be able to eliminate the unnecessary > movss. It hasn't shown up on my radar so I haven't really thought out > the right way to...

...structions. I saw this in x86InstSSE.td: // FIXME: may not be able to eliminate this movss with coalescing the src and // dest register classes are different. We really want to write this pattern // like this: // def : Pat<(f32 (vector_extract (v4f32 VR128:$src), (iPTR 0))), // (f32 FR32:$src)>; (this is actually a very useful and important pattern, I wish it was available!) I had actually written my pattern in a similar style before I found this. When I tried to build, tblgen complained about the pattern being of an unknown type (didn't match Instruction or SDNodeXForm)....

On Jul 26, 2012, at 9:43 AM, dag at cray.com wrote: > Jakob Stoklund Olesen <jolesen at apple.com> writes: > >> As far as I can tell, all sub-register operations involving sub_ss and >> sub_sd can simply be replaced with COPY_TO_REGCLASS: >> >> def : Pat<(v4i32 (X86Movsd VR128:$src1, VR128:$src2)), >> (VMOVSDrr VR128:$src1,

...: > > // FIXME: may not be able to eliminate this movss with coalescing the > src and > // dest register classes are different. We really want to write this > pattern > // like this: > // def : Pat<(f32 (vector_extract (v4f32 VR128:$src), (iPTR 0))), > // (f32 FR32:$src)>; > > (this is actually a very useful and important pattern, I wish it was > available!) Right. It would be nice to be able to eliminate the unnecessary movss. It hasn't shown up on my radar so I haven't really thought out the right way to model this. I can see a cou...

Hey guys, Are spills/reloads of AVX registers using aligned stores/loads? I can't seem to find the code that aligns the stack slots to 32-bytes. Could someone point me in the right direction? Thanks, Cameron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110825/b5724dec/attachment.html>

...32-bytes. Could > someone point me in the right direction? The register class has 256-bit spill alignment: def VR256 : RegisterClass<"X86", [v32i8, v16i16, v8i32, v4i64, v8f32, v4f64], 256, (sequence "YMM%u", 0, 15)> { let SubRegClasses = [(FR32 sub_ss), (FR64 sub_sd), (VR128 sub_xmm)]; } /jakob