search for: x86instrsse

...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: > > I tried to add an 'OptForSize' requirement to a pattern in X86InstrSSE.td, > > but it appears to be ignored. However, the condition was detected when > > specified as a predicate. > > > > So this doesn't work: > > def : Pat<(v2f64 (X86VBroadcast (loadf64 addr:$src))), (VMOVDDUPrm > addr: > > $src)>, > >...

I am new to the LLVM backends, I am wondering how instruction selection is done in LLVM backends, I looked at the .td files in Target/X86, they all seem to be small and do not deal with common X86 instructions, i.e. mov, push, pop, etc. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL:

I'm working on changing the MMX implementation to use intrinsics in all cases, which should stop various optimization passes from creating MMX instructions that screw up the x87 stack. Right now the MMX instructions are split between X86InstrMMX.td and X86InstrSSE.td, presumably on the historical grounds that some of them weren't introduced until SSE or SSSE3, and require support for that feature to work. I'm thinking it would be cleaner to keep them all in X86InstrMMX. Does anyone have an opinion about this?

...# r3 = (45 << 16) >> iohl $3, 5 # r3 |= 5 >> >> I tried: >> >> def : Pat<(i32 imm:$imm), >> (IOHL (ILHU (HI16 imm:$imm)), (LO16 imm:$imm))>; > > It is possible to write multi-instruction pattern, e.g. > X86InstrSSE.td line 1911. But how are you defining HI16 and LO16? > Sounds like you want to define them as SDNodeXform that returns upper > and lower 16 bits respectively. Take a look at PSxLDQ_imm in > X86InstrSSE.td as an example. Another good example is the PPC backend, which has the exact same is...

...lt;> but that didn't solve the pattern problems I mentioned above. All of this complication gets multipled with AVX because AVX recodes all of the legacy SSE instructions using VEX to provide three-address forms. So if we were to follow the existing sceheme, we would duplicate *all* of X86InstrSSE.td and edit patterns to match three-address modes and then add the 256-bit patterns on top of that, effectively duplicating X86InstrSSE.td a second time. This is not scalable. So what I've done is a little experiment to see if I can unify all SSE and AVX SIMD instructions under one framew...

...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 templates need to be somewhere accessible to both sets of patterns. Then I'll start with a simple instruction like ADDPS/D...

...instructions share a set of common patterns so that we can have a more maintainable machine description (e.g. SS, SD, PS, PD, 128-bit, 256-bit ADD all look similar other than opcode prefixes). This patch merely moves some common pattern fragments (memop, alignedload, etc.) to a file separate from X86InstrSSE.td so that all current x86 SIMD implementations can still use the classes while the transition happens. Ok to commit? -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: simdfrags.patch Type: text/x-patch Size: 31214 bytes Desc:...

...en generate all the required matching code. > All of this complication gets multipled with AVX because AVX recodes > all of > the legacy SSE instructions using VEX to provide three-address > forms. So if > we were to follow the existing sceheme, we would duplicate *all* of > X86InstrSSE.td and edit patterns to match three-address modes and > then add the > 256-bit patterns on top of that, effectively duplicating > X86InstrSSE.td a > second time. > > This is not scalable. I agree, I think it is unfortunate that AVX decided to do this at an architectural le...

...common patterns > so that we can have a more maintainable machine description (e.g. SS, > SD, PS, PD, 128-bit, 256-bit ADD all look similar other than opcode > prefixes). > > This patch merely moves some common pattern fragments (memop, > alignedload, etc.) to a file separate from X86InstrSSE.td so that all > current x86 SIMD implementations can still use the classes while the > transition happens. > > Ok to commit? I'm Ok with this patch. Despite that, I think we should discuss the ones to come, If you really go "tablegen auto generates everything" as I'...

Chris Lattner wrote: >>It is possible to write multi-instruction pattern, e.g. >>X86InstrSSE.td line 1911. But how are you defining HI16 and LO16? >>Sounds like you want to define them as SDNodeXform that returns upper >>and lower 16 bits respectively. Take a look at PSxLDQ_imm in >>X86InstrSSE.td as an example. > > > Another good example is the PPC backend, wh...

...gister): > > ilhu $3, 45 # r3 = (45 << 16) > iohl $3, 5 # r3 |= 5 > > I tried: > > def : Pat<(i32 imm:$imm), > (IOHL (ILHU (HI16 imm:$imm)), (LO16 imm:$imm))>; It is possible to write multi-instruction pattern, e.g. X86InstrSSE.td line 1911. But how are you defining HI16 and LO16? Sounds like you want to define them as SDNodeXform that returns upper and lower 16 bits respectively. Take a look at PSxLDQ_imm in X86InstrSSE.td as an example. > > - The return instruction for Cell SPU is "bi $lr". How do...

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

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

...operands invalid for `popcnt' The problem is that the mac assembler does not support length suffixes on the popcnt instruction (e.g. {w,l,q} suffixes). GCC handles this by not adding the suffixes to popcnt for darwin targets [1]. Indeed if I change the instruction definition in lib/Target/X86/X86InstrSSE.td to drop the suffix, then it works fine. I can submit a patch to that effect, but what is the proper way to handle this? [1]: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34497#c14

On Apr 30, 2009, at 3:59 PM, David Greene wrote: > Here's the big RFC. > > > Of course we would not transition away from X86InstrSSE.td until > X86InstrSIMD.td is proven to cover all current uses of SSE correctly. > > The pros of the scheme: > > * Unify all "important" x86 SIMD instructions into one framework and > provide > consistency While almost all of this sounds pretty great to me, since...

I was able to resolve my previous question about dealing with custom loads/stores, and following Chris' suggestion, the IBM Cell SPU backend can generate code for "int main(void) { return 0; }" without crashing llc. There's a lot of work still to be done... like getting frame offsets correctly computed and hauling in the raft of intrinsics that the Cell SDK defines. Three quick

Bruno Cardoso Lopes <bruno.cardoso at gmail.com> writes: >> This patch merely moves some common pattern fragments (memop, >> alignedload, etc.) to a file separate from X86InstrSSE.td so that all >> current x86 SIMD implementations can still use the classes while the >> transition happens. >> >> Ok to commit? > > I'm Ok with this patch. So I'm getting some mysterious failures with this. Currently TOT is failing six tests, which look lik...

I tried to add an 'OptForSize' requirement to a pattern in X86InstrSSE.td, but it appears to be ignored. However, the condition was detected when specified as a predicate. So this doesn't work: def : Pat<(v2f64 (X86VBroadcast (loadf64 addr:$src))), (VMOVDDUPrm addr: $src)>, *Requires<[OptForSize**]>*; But this does: * let Predic...

For anyone interested, X86InstrSSE.td makes extensive use of multiclasses now if people are looking for examples other than the sparc backend. -Chris -- http://nondot.org/sabre/ http://llvm.org/

...[8|16|32] and > crc64.[8|16|32] have been renamed to .crc32.64.[8|64]. > > > > Added: > llvm/trunk/test/CodeGen/X86/sse42_64.ll > Modified: > llvm/trunk/include/llvm/IntrinsicsX86.td > llvm/trunk/lib/Analysis/ValueTracking.cpp > llvm/trunk/lib/Target/X86/X86InstrSSE.td > llvm/trunk/lib/Transforms/InstCombine/InstCombineSimplifyDemanded.cpp > llvm/trunk/lib/VMCore/AutoUpgrade.cpp > llvm/trunk/test/CodeGen/X86/sse42.ll > llvm/trunk/test/Transforms/InstCombine/x86-crc32-demanded.ll > > Modified: llvm/trunk/include/llvm/IntrinsicsX86...