search for: hassse1

..., 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 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 ve...

...6 .td files. For example, in X86InstrFormats.td: // SSE1 Instruction Templates: // // SSI - SSE1 instructions with XS prefix. class SSI<bits<8> o, Format F, dag outs, dag ins, string asm, list<dag> pattern> : I<o, F, outs, ins, asm, pattern>, XS, Requires<[HasSSE1]>; // SSE3 Instruction Templates: // S3SI - SSE3 instructions with XSrefix. class S3SI<bits<8> o, Format F, dag outs, dag ins, string asm, list<dag> pattern> : I<o, F, outs, ins, asm, pattern>, XS, Requires<[HasSSE3]>; The only difference here is the p...

...rmats.td: > > // SSE1 Instruction Templates: > // > // SSI - SSE1 instructions with XS prefix. > > class SSI<bits<8> o, Format F, dag outs, dag ins, string asm, list<dag> > pattern> > > : I<o, F, outs, ins, asm, pattern>, XS, Requires<[HasSSE1]>; > > // SSE3 Instruction Templates: > // S3SI - SSE3 instructions with XSrefix. > > class S3SI<bits<8> o, Format F, dag outs, dag ins, string asm, list<dag> > pattern> > > : I<o, F, outs, ins, asm, pattern>, XS, Requires<[HasSSE3]&gt...

...R 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 as well but again no luck. Is there a simple way to > make it work with LLVM 3.0 or should I consider u...

...n Templates: >> // >> // SSI - SSE1 instructions with XS prefix. >> >> class SSI<bits<8> o, Format F, dag outs, dag ins, string asm, >> list<dag> >> pattern> >> >> : I<o, F, outs, ins, asm, pattern>, XS, Requires<[HasSSE1]>; >> >> // SSE3 Instruction Templates: >> // S3SI - SSE3 instructions with XSrefix. >> >> class S3SI<bits<8> o, Format F, dag outs, dag ins, string asm, >> list<dag> >> pattern> >> >> : I<o, F, outs, ins, asm,...

...features as function attribute : "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 t...

On Tuesday 31 March 2009 13:53, Dan Gohman wrote: > > class SSI<bits<8> o, Format F, dag outs, dag ins, string asm, > > list<dag> pattern> > > > > : SSIb<o, F, outs, ins, asm, pattern>, Requires<HasSSE1>; > > Is this just factoring out the ", XS" part? As presented, it looks like > this change would introduce more redundancy that it would eliminate. It's factoring out XS and the other encoding bits, but the real goal is to separate out the Requires<> predicates. D...

Can someone explain the magic behind the Pat<> construct and tblgen. >From X86InstrSSE.td: def : Pat<(v4f32 (vector_shuffle VR128:$src, (undef), MOVDDUP_shuffle_mask)), (MOVLHPSrr VR128:$src, VR128:$src)>, Requires<[HasSSE1]>; Where's the code in tblgen to emit the matching code for this? I'm trying to extend it so that Pat<> can be used as a general subclass for AVX: class Base<dag pat, dag result, ...> : Pat<dag, result> ...; multiclass foo<dag pat, dag result, ...> { def A :...

...eation 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: [(set FR32:$dst, fp32imm0)] ? Thanks in advance. -------------- next part -------------- An HTML attachme...

...quot;Subtarget->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...

...p I m trying this but unable to solve. Thank You On Tue, Jul 24, 2018 at 4:44 PM, hameeza ahmed <hahmed2305 at gmail.com> wrote: > Hello, > Do i need to change following function; > > unsigned X86TTIImpl::getNumberOfRegisters(bool Vector) { > if (Vector && !ST->hasSSE1()) > return 0; > > if (ST->is64Bit()) { > if (Vector && ST->hasAVX512()) > return 32; > return 16; > } > return 8; > } > > to > > if (ST->is2048Bit()) { > if (Vector && ST->hasAVX512()) > retu...

...a guard around the XMM spill code that checks for %al != 0. Therefore I believe it would be "in the spirit" of -no-implicit-float to remove the NoImplicitFloatOps check from the following: X86ISelLowering.cpp : get64BitArgumentXMMs() if (isSoftFloat || NoImplicitFloatOps || !Subtarget.hasSSE1()) // Kernel mode asks for SSE to be disabled, so there are no XMM argument // registers....

Thank You. Right now to see the effect i did following changes; unsigned X86TTIImpl::getRegisterBitWidth(bool Vector) { if (Vector) { if (ST->hasAVX512()) return 65536; here i changed 512 to 65536. Then in loopvectorize.cpp i did following; assert(MaxVectorSize <= 2048 && "Did not expect to pack so many elements" " into

Hi! when reading X86Subtarget.h the methods seem a bit disordered, therefore I would propose to sort them new: -getTargetTriple() -cpu features (e.g. hasSSE1()) -os types (e.g. isTargetDarwin()) -object types (e.g. isTargetELF()) -callconv related functions (e.g. isTargetWin64(), consider renaming to isCallConvWin64(), getStackAlignment()) -pic functions perhaps my problem of generating elf objects on windows can be easily solved by creating a new...

>>> 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++. >> >>>

...set FR32:$dst, (OpNode FR32:$src1, FR32:$src2))]> { let isCommutable = Commutable; } >From X86InstrFormats.td: class SSI<bits<8> o, Format F, dag outs, dag ins, string asm, list<dag> pattern> : I<o, F, outs, ins, asm, pattern>, XS, Requires<[HasSSE1]>; For AVX we would need a different set of format classes because while AVX could reuse the existing XS class (it's recoded as part of the VEX prefix so we still need the information XS provides), "Requires<[HasSSE1]>" is certainly inappropriate. Initially I started fac...

On Aug 10, 2013, at 7:32 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote: >> 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++. >

...ot;="+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 va...

...spill code that checks for %al != 0. > > Therefore I believe it would be "in the spirit" of -no-implicit-float to remove the NoImplicitFloatOps check from the following: > > X86ISelLowering.cpp : get64BitArgumentXMMs() > if (isSoftFloat || NoImplicitFloatOps || !Subtarget.hasSSE1()) > // Kernel mode asks for SSE to be disabled, so there are no XMM argument > // registers. > return None; > > Does this seem like a reasonable idea? > > Thanks, > > Salim Nasser > Wind River > _______________________________________________ > LLVM...

...to NoTTI. But, it could also be that you don’t have the right sub target (in which case you need to set the right cpu, “-mcpu” in opt, when the target machine is created): unsigned X86TTI::getRegisterBitWidth(bool Vector) const { if (Vector) { if (ST->hasAVX()) return 256; if (ST->hasSSE1()) return 128; return 0; } if (ST->is64Bit()) return 64; return 32; } > > It's not picking the target information, although I tried with and > without the target triple in the module > > Any idea what could be wrong? > > Frank > > > On 26...