search for: hassse2

...u have a micro-architecture where there's actually a difference), this can be achieved by having instruction selection select the right instructions. For example, find code like this in X86InstrSSE.td: def : Pat<(alignedloadv2i64 addr:$src), (MOVAPSrm addr:$src)>, Requires<[HasSSE2]>; def : Pat<(loadv2i64 addr:$src), (MOVUPSrm addr:$src)>, Requires<[HasSSE2]>; and change it to not select MOVAPS for that microarchitecture, for example. Dan

Hi, I have a problem with creating a MFENCE on X86 with SSE In X86InstrSSE.td, a MFENCE is def MFENCE : I<0xAE, MRM6m, (outs), (ins), "mfence", [(int_x86_sse2_mfence)]>, TB, Requires< [HasSSE2]>; In X86CodeEmitter.cpp in emitInstruction case X86II::MRM6m: case X86II::MRM7m: { intptr_t PCAdj = (CurOp+4 != NumOps) ? (MI.getOperand(CurOp+4).isImm() ? X86InstrInfo::sizeOfImm (Desc) : 4) : 0; ... If I'm reading the code correctly, the NumOps is 0 and CurOp is 0 so...

...de. 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 as well but again no luck. Is there a simple way to make it work with LLVM 3.0 or should I consider updating to a later version? Thanks, Nicolas

On Tuesday 02 September 2008 16:47, Evan Cheng wrote: > On Sep 2, 2008, at 10:42 AM, David Greene wrote: > > Is there an easy way to get the MVT::ValueType of a MachineInstruction > > MachineOperand? For example, the register operand of an x86 MOVAPD > > should > > have an MVT::ValueType of v2f64. A MOVAPS register operand should > > have an > >

...uot;target-features"="+mmx" In the SelectionDAG phase in file "X86ISelLowering.cpp", i checked in one of the function what is the subtarget feature by calling few routines of Subtarget. Subtarget->hasMMX() ------ true Subtarget->hasSSE1() ------ true Subtarget->hasSSE2() ------ true These functions just compare the X86SSELevel with subtarget enum values like MMX, SSE1, SSE2 etc. hasMMX() { return X86SSELevel >= MMX}; // similar for others Now, enum values start from MMX and goes on increasing with SSE1, SSE2, etc. For the above test case, the X86SSELevel...

...before the final code is emitted. If you're using the X86 target, then the class and the function is already there: lib/Target/X86/X86TargetMachine.cpp: bool X86PassConfig::addPreEmitPass() { bool ShouldPrint = false; if (getOptLevel() != CodeGenOpt::None && getX86Subtarget().hasSSE2()) { addPass(createExecutionDependencyFixPass(&X86::VR128RegClass)); ShouldPrint = true; } if (getX86Subtarget().hasAVX() && UseVZeroUpper) { addPass(createX86IssueVZeroUpperPass()); ShouldPrint = true; } return ShouldPrint; } -Krzysztof -- Qualcom...

...2008, at 10:46 PM, Mon Ping Wang wrote: > Hi, > > I have a problem with creating a MFENCE on X86 with SSE > > In X86InstrSSE.td, a MFENCE is > def MFENCE : I<0xAE, MRM6m, (outs), (ins), > "mfence", [(int_x86_sse2_mfence)]>, TB, Requires< > [HasSSE2]>; > > In X86CodeEmitter.cpp in emitInstruction > > case X86II::MRM6m: case X86II::MRM7m: { > intptr_t PCAdj = (CurOp+4 != NumOps) ? > (MI.getOperand(CurOp+4).isImm() ? X86InstrInfo::sizeOfImm > (Desc) : 4) : 0; > ... > > If I'm reading the code corr...

...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 as well but again no luck. Is there a simple way to > make it work with LLVM 3.0 or should I consider updating to a later version? That particular issue doesn't look famil...

...rote: > >> Hi, >> >> I have a problem with creating a MFENCE on X86 with SSE >> >> In X86InstrSSE.td, a MFENCE is >> def MFENCE : I<0xAE, MRM6m, (outs), (ins), >> "mfence", [(int_x86_sse2_mfence)]>, TB, Requires< >> [HasSSE2]>; >> >> In X86CodeEmitter.cpp in emitInstruction >> >> case X86II::MRM6m: case X86II::MRM7m: { >> intptr_t PCAdj = (CurOp+4 != NumOps) ? >> (MI.getOperand(CurOp+4).isImm() ? X86InstrInfo::sizeOfImm >> (Desc) : 4) : 0; >> ... >> >&...

...->hasCMov()">; def NoCMov : Predicate<"!Subtarget->hasCMov()">; It would be simple to define: def NoCMov : Predicate<(not HasCMov)>; And the tool would be able to infer that the predicates are disjoint. Similarly: def : Always<(or HasSSE1, (not HasSSE2))>; can be used to infer an implication. Many pattern predicates could be expressed in a DSL, but we should still make it possible to use C++ code. Thanks, /jakob -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/atta...

...(v2f64 (scalar_to_vector (loadf64 addr: $src2))), SHUFP_shuffle_mask:$sm)), (SHUFPDrri (v2f64 (MOVSD2PDrm addr:$src1)), (v2f64 (MOVSD2PDrm addr:$src2)), SHUFP_shuffle_mask:$sm)>, Requires<[HasSSE2]>; } // AddedComplexity After much hacking of tblgen, I finally convinced it to generate some somewhat-seemingly-reasonably-correct matching and generation code. What's happening is that that generation code constructs two MOVSD2PD instructions. These are all brand-new SDNodes. The ver...

On 1/7/2013 1:53 PM, Sergei Larin wrote: > > Also, how much performance are you willing to sacrifice to do what you > do? Maybe turning off scheduling all together is an acceptable solution? Or insert the calls after scheduling. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Krzysztof, This would be ideal. How can I do the instrumentation pass after the instruction scheduling? Xu Liu Quoting Krzysztof Parzyszek <kparzysz at codeaurora.org>: > On 1/7/2013 1:53 PM, Sergei Larin wrote: >> >> Also, how much performance are you willing to sacrifice to do what you >> do? Maybe turning off scheduling all together is an acceptable solution?

...(v2f64 (scalar_to_vector (loadf64 addr: $src2))), SHUFP_shuffle_mask:$sm)), (SHUFPDrri (v2f64 (MOVSD2PDrm addr:$src1)), (v2f64 (MOVSD2PDrm addr:$src2)), SHUFP_shuffle_mask:$sm)>, Requires<[HasSSE2]>; } // AddedComplexity It turns out you can't actually write a pattern like this with tblgen as-is. There's a bug where it outputs multiple definitions of some local variables. I've patched that here and hope to send it upstream once I get approval. But let's say you _coul...

>>> I like the idea of sharing code between IR and MI passes through an >>> abstract interface. I think that later stages in the IR pipeline also >>> need an instruction optimizer instead of a canonicalizer. >>> >>> An alternative approach would be to describe these transformations in a >>> DSL instead of C++. >> >>>

...you're using the X86 target, then the class and the > function is already there: > > lib/Target/X86/X86TargetMachine.cpp: > > bool X86PassConfig::addPreEmitPass() { > bool ShouldPrint = false; > if (getOptLevel() != CodeGenOpt::None && > getX86Subtarget().hasSSE2()) { > addPass(createExecutionDependencyFixPass(&X86::VR128RegClass)); > ShouldPrint = true; > } > > if (getX86Subtarget().hasAVX() && UseVZeroUpper) { > addPass(createX86IssueVZeroUpperPass()); > ShouldPrint = true; > } > >...

...o_vector (loadf64 > addr: > $src2))), > SHUFP_shuffle_mask:$sm)), > (SHUFPDrri (v2f64 (MOVSD2PDrm addr:$src1)), > (v2f64 (MOVSD2PDrm addr:$src2)), > SHUFP_shuffle_mask:$sm)>, Requires<[HasSSE2]>; > } // AddedComplexity > > After much hacking of tblgen, I finally convinced it to generate some > somewhat-seemingly-reasonably-correct matching and generation code. > > What's happening is that that generation code constructs two MOVSD2PD > instructions. These are...

...addr:$src1))), (v2f64 (scalar_to_vector (loadf64 addr:$src2))), SHUFP_shuffle_mask:$sm), (SHUFPDrri (MOVSD2PDrm addr:$src1), (MOVSD2PDrm addr:$src2), SHUFP_shuffle_mask:$sm)>, Requires<[HasSSE2]>; } // AddedComplexity I believe the problem with the tblgen in trunk is that it doesn't know how to support patterns with two memory operands. I've attached the code that the hacked tblgen spits out from EmitResultCode for this pattern. The remaining problem is that this code does...

On Fri, October 3, 2008 9:10 am, David Greene wrote: > On Thursday 02 October 2008 19:32, Dan Gohman wrote: > >> Looking at your dump() output above, it looks like the pre-selection >> loads have multiple uses, so even though you've managed to match a >> larger pattern that incorporates them, they still need to exist to >> satisfy some other users. > > Yes,

...the lists advice on what people think is > the best approach to resolving this issue so I can make the changes? The changes just mentioned looks correct. [bg]The problem is I am not sure of the best approach to take here. For example, one possible approach I can see is to following that of the HasSSE2 constraint and introduce something like the follow to X86.td: def IsIntelAsmWriter : Predicate<"Subtarget.isFlavorIntel()">; def IsATTAsmWriter : Predicate<"!Subtarget.isFlavorIntel()">; and then in X86InstrInfo.td make changes something like: def SHL8mCLInte...