search for: memopv4f32

...match certain shuffle instructions in .td files: one through the traditional shuffle operators like unpckl and shufp and another through these special X86* operators. This is reflected in X86InstrSSE.td: "Traditional": defm VUNPCKLPS: sse12_unpack_interleave<0x14, unpckl, v4f32, memopv4f32, VR128, f128mem, "unpcklps\t{$src2, $src1, $dst|$dst, $src1, $src2}", SSEPackedSingle>, VEX_4V; "New-style": def : Pat<(v4f32 (X86Unpcklps VR128:$src1, (memopv4f32 addr:$src2))), (VUNPCKLPSrm VR128:$src1, addr:$src2)&gt...

In ToT, LowerVECTOR_SHUFFLE for x86 has this code: if (X86::isUNPCKLMask(SVOp)) getTargetShuffleNode(getUNPCKLOpcode(VT) dl, VT, V1, V2, DAG); why would this not be: if (X86::isUNPCKLMask(SVOp)) return SVOp; I'm trying to add support for VUNPCKL and am getting into trouble because the existing code ends up creating: VUNPCKLPS load load which is badness come selection

...ng thread appears to talk about >> something similar:http://thread.gmane.org/gmane.comp.compilers.llvm.devel/9476/focus=9478 > > Looking at LLVM's definition of the rcpps intrinsic, this looks like > a bug to me (RCPPSm_Int uses a plain load; it looks like it > should be using memopv4f32). > > Dan > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

...ddressed. The following thread appears to talk about > something similar:http://thread.gmane.org/gmane.comp.compilers.llvm.devel/9476/focus=9478 Looking at LLVM's definition of the rcpps intrinsic, this looks like a bug to me (RCPPSm_Int uses a plain load; it looks like it should be using memopv4f32). Dan

...talk about >>> something similar:http://thread.gmane.org/gmane.comp.compilers.llvm.devel/9476/focus=9478 >> >> Looking at LLVM's definition of the rcpps intrinsic, this looks like >> a bug to me (RCPPSm_Int uses a plain load; it looks like it >> should be using memopv4f32). >> >> Dan >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________...

...number of foundational templates that shouldn't affect anything else. I'll put those in next. Then the fun begins. The first step is to move some some of the templates from X86InstSSE.td out into a new file (I've called it X86InstrFragmentsSIMD.td in our tree). These are things like memopv4f32, alignedload, etc. These are foundational things we need for both AVX and SSE. The goal is to eventually replace X86InstrSSE.td entirely with a set of patterns that covers all SIMD instructions. But that's going to be gradual so we need to maintain both as we go along. So these foundational...

...td files: one through the > traditional shuffle operators like unpckl and shufp and another through > these special X86* operators. > > This is reflected in X86InstrSSE.td: > > "Traditional": > > defm VUNPCKLPS: sse12_unpack_interleave<0x14, unpckl, v4f32, memopv4f32, > VR128, f128mem, "unpcklps\t{$src2, $src1, $dst|$dst, $src1, $src2}", > SSEPackedSingle>, VEX_4V; > "New-style": > > def : Pat<(v4f32 (X86Unpcklps VR128:$src1, (memopv4f32 addr:$src2))), > (VUNPCKLPSrm V...

Hi all, I think I might have found a potential bug when using SSE intrinsic and unaligned memory. Here's the code to reproduce it: #include "llvm/Module.h" #include "llvm/Intrinsics.h" #include "llvm/Instructions.h" #include "llvm/ModuleProvider.h" #include "llvm/ExecutionEngine/JIT.h" #include

.... def PSrm : PSI<opc, MRMSrcMem, (outs VR128:$dst), (ins VR128:$src1, f128mem:$src2), !strconcat(OpcodeStr, "ps\t{$src2, $dst|$dst, $src2}"), [(set VR128:$dst, (OpNode VR128:$src1, (memopv4f32 addr:$src2)))]>; } These are all essentially the same except that ModRM formats, types and register classes change. For patterns that access memory there are special "memory access operators" like memopv4f32. But the base pattern of dest = src1 op src2 is the same. Worse yet: l...