search for: hassse3

Hi Bruno, > Some comments: > > + // Try to synthesize horizontal adds from adds of shuffles. > + if (((Subtarget->hasSSE3()&& (VT == MVT::v4f32 || VT == MVT::v2f64)) || > + (Subtarget->hasAVX()&& (VT == MVT::v8f32 || VT == MVT::v4f64)))&& > + isHorizontalBinOp(LHS, RHS, true)) > > 1) You probably want to do something like: > > "bool HasHorizontalArith = Su...

...how I did it you will see > why!). > I'm sending the patch for comments, and in the hope that someone will > explain > how I should be doing the tablegen bits. This is awesome :D Some comments: + // Try to synthesize horizontal adds from adds of shuffles. + if (((Subtarget->hasSSE3() && (VT == MVT::v4f32 || VT == MVT::v2f64)) || + (Subtarget->hasAVX() && (VT == MVT::v8f32 || VT == MVT::v4f64))) && + isHorizontalBinOp(LHS, RHS, true)) 1) You probably want to do something like: "bool HasHorizontalArith = Subtarget->hasSSE3() || Su...

...day, September 22, 2011 3:14 PM To: Bruno Cardoso Lopes Cc: LLVMdev Subject: Re: [LLVMdev] Patch to synthesize x86 hadd instructions; need help with the tablegen bits Hi Bruno, > Some comments: > > + // Try to synthesize horizontal adds from adds of shuffles. > + if (((Subtarget->hasSSE3()&& (VT == MVT::v4f32 || VT == MVT::v2f64)) || > + (Subtarget->hasAVX()&& (VT == MVT::v8f32 || VT == MVT::v4f64)))&& > + isHorizontalBinOp(LHS, RHS, true)) > > 1) You probably want to do something like: > > "bool HasHorizontalArith = Su...

This patch synthesizes haddps/haddpd/hsubps/hsubpd instructions from floating point additions and subtractions of appropriate vector shuffles. To do this I introduced new x86 FHADD and FHSUB opcodes. These need to be wired up somehow in the .td file to the appropriate instructions. Since I have no idea how tablegen works I just hacked it in horribly. It works, but breaks support for the hadd

...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 parameter to Requires. There are many more examples and this gets worse with AVX. I'd like to propose a refactoring that looks something like this: // SSE Instruction Templates: // // SSI - SSE Instructions with XS prefix class SSI<bits<8> o...

...lt;[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 parameter to Requires. There are many more > examples and this gets worse with AVX. > > I'd like to propose a refactoring that looks something like this: > > // SSE Instruction Templates: > // > // SSI - SSE Instructions wit...

...3 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 parameter to Requires. There are >> many more >> examples and this gets worse with AVX. [...] > Actually, I meant to keep the existing class names intact to avoid > global > changes. So what I'm proposing is ac...

...ion @@ -131,6 +200,14 @@ std::string sys::getHostCPUName() { unsigned Model = 0; DetectX86FamilyModel(EAX, Family, Model); + union { + unsigned u[3]; + char c[12]; + } text; + + GetX86CpuIDAndInfo(0, &EAX, text.u+0, text.u+2, text.u+1); + + unsigned MaxLeaf = EAX; bool HasSSE3 = (ECX & 0x1); bool HasSSE41 = (ECX & 0x80000); // If CPUID indicates support for XSAVE, XRESTORE and AVX, and XGETBV @@ -138,15 +215,12 @@ std::string sys::getHostCPUName() { // switch, then we have full AVX support. const unsigned AVXBits = (1 << 27) | (1 << 28);...

I agree with Tim, you need to implement a GetCpuIDAndInfoEx function in Host.cpp and pass the correct value to ecx. Also you need to verify that 7 is a valid leaf because an invalid leaf is defined to return the highest supported leaf on that processor. So if a processor supports say leaf 6 and not leaf 7, then an access leaf 7 will return the data from leaf 6 causing unrelated bits to be

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

...esn't have @@ -176,15 +179,16 @@ if (Subtarget->is64Bit()) { setOperationAction(ISD::FP_TO_UINT , MVT::i64 , Expand); setOperationAction(ISD::FP_TO_UINT , MVT::i32 , Promote); - } else { + } else if (!UseSoftFloat) { if (X86ScalarSSEf32 && !Subtarget->hasSSE3()) // Expand FP_TO_UINT into a select. // FIXME: We would like to use a Custom expander here eventually to do // the optimal thing for SSE vs. the default expansion in the legalizer. - setOperationAction(ISD::FP_TO_UINT , MVT::i32 , Expand); + setOperationAction(IS...