search for: vr256

...39;s a big improvement over the old system and provides the context that code generation for AVX needs. This is great! I'm asking because I'm having some trouble converting some AVX patterns over to the new system. I'm getting this error from tblgen: VyPERM2F128PDirrmi: (set:isVoid VR256:v4i64:$dst, (vector_shuffle:v4i64 VR256:v4i64:$src1, (ld:v4i64 addr:iPTR:$src2)<<P:Predicate_unindexedload>><<P:Predicate_load>><<P:Predicate_memop>>)<<P:Predicate_vperm2f128>><<X:SHUFFLE_get_vperm2f128_imm>>) llvm/lib/Target/X86/X86InstrS...

Hello, I am getting this error. What instruction is required to be implemented? LLVM ERROR: Cannot select: t22: v32i32 = vselect t724, t11, t16 t724: v32i32,ch = load<LD128[FixedStack1]> t723, FrameIndex:i64<1>, undef:i64 t659: i64 = FrameIndex<1> t10: i64 = undef t11: v32i32,ch = load<LD128[%sunkaddr45](align=4)(tbaa=<0x481f1e8>)> t0, t8, undef:i64

Can anyone puzzle out what tblgen is trying to tell me here? VR256:v32i8:$src MD0.VMOVDQA_256mr: (st:isVoid VR256:v32i8:$src, addr:iPTR: $dst)<<P:Predicate_unindexedstore>><<P:Predicate_store>><<P:Predicate_alignedstore>> /ptmp/dag/universal_build/debug/DEFAULT/llvm/tblgen: In MD0.VMOVDQA_256mr: Type inference contradiction fo...

...ector_osta_node_mri_256<0x19, MRMDestReg, MRMDestMem, "extractf128", undef, X86f32, X86i32i8, // rr [(set VR128:$dst, (v4f32 (vector_shuffle (v8f32 undef), (v8f32 VR256:$src1), VEXTRACTF128_shuffle_mask:$src2)))]>; (This is simplified for the sake of exposition but this gets the idea across). TableGen reports a type contradition: VEXTRACTF128_256mri: (st:isVoid (vector_shuffle:v4f32 (undef:v8f32), VR256:v8f32:$src1, (bu...

David Greene <dag at cray.com> writes: > I'm asking because I'm having some trouble converting some AVX patterns > over to the new system. I'm getting this error from tblgen: > > VyPERM2F128PDirrmi: (set:isVoid VR256:v4i64:$dst, (vector_shuffle:v4i64 VR256:v4i64:$src1, (ld:v4i64 addr:iPTR:$src2)<<P:Predicate_unindexedload>><<P:Predicate_load>><<P:Predicate_memop>>)<<P:Predicate_vperm2f128>><<X:SHUFFLE_get_vperm2f128_imm>>) > llvm/lib/Target/X86/X86I...

...i_256<0x19, MRMDestReg, >                      MRMDestMem, "extractf128", undef, X86f32, X86i32i8, >                   // rr >                   [(set VR128:$dst, >                         (v4f32 (vector_shuffle >                                     (v8f32 undef), (v8f32 VR256:$src1), >                                     VEXTRACTF128_shuffle_mask:$src2)))]>; > > (This is simplified for the sake of exposition but this gets the idea across). > > TableGen reports a type contradition: > > VEXTRACTF128_256mri:    (st:isVoid (vector_shuffle:v4f32 (unde...

...d at obbligato.org> wrote: > David Greene <dag at cray.com> writes: > >> I'm asking because I'm having some trouble converting some AVX patterns >> over to the new system.  I'm getting this error from tblgen: >> >> VyPERM2F128PDirrmi:   (set:isVoid VR256:v4i64:$dst, (vector_shuffle:v4i64 VR256:v4i64:$src1, (ld:v4i64 addr:iPTR:$src2)<<P:Predicate_unindexedload>><<P:Predicate_load>><<P:Predicate_memop>>)<<P:Predicate_vperm2f128>><<X:SHUFFLE_get_vperm2f128_imm>>) >> llvm/lib/Target/X86/...

Hey guys, Are spills/reloads of AVX registers using aligned stores/loads? I can't seem to find the code that aligns the stack slots to 32-bytes. Could someone point me in the right direction? Thanks, Cameron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110825/b5724dec/attachment.html>

...lly wrote: > Hey guys, > > Are spills/reloads of AVX registers using aligned stores/loads? Yes. > I can't > seem to find the code that aligns the stack slots to 32-bytes. Could > someone point me in the right direction? The register class has 256-bit spill alignment: def VR256 : RegisterClass<"X86", [v32i8, v16i16, v8i32, v4i64, v8f32, v4f64], 256, (sequence "YMM%u", 0, 15)> { let SubRegClasses = [(FR32 sub_ss), (FR64 sub_sd), (VR128 sub_xmm)]; } /jakob

Hi, I have some newly defined intrinsic functions in my llvm IR code, which I want to translate to X86 instruction set. As a first step, I want to be able to generate "nop" for these instructions, so the program at least compiles successfully. The call to my intrinsic function looks like this in the IR: call void @llvm.X(i16 %43) >From what I understand it may be possible to

...: > Looks to me like the alignment is specified in tablegen. From Target.td: > > class RegisterClass<string namespace, list<ValueType> regTypes, int alignment, > dag regList, RegAltNameIndex idx = NoRegAltName> > > X86RegisterInfo.td: > > def VR256 : RegisterClass<"X86", [v32i8, v16i16, v8i32, v4i64, v8f32, v4f64], > 256, (sequence "YMM%u", 0, 15)>; > def VR256X : RegisterClass<"X86", [v32i8, v16i16, v8i32, v4i64, v8f32, v4f64], > 256, (seque...

...m : Instr< [(set (type regclass:$dst), (type (opcode (type regclass:$src1), (type addr:$src2))))]>; } } multiclass avx_binop<opcode> { for type = [f32, f64, v4f32, v2f64, v8f32, v4f64] regclass = [FP32, FP64, VR128, VR128, VR256, VR256] prefix = [x, x, x, x, y, y] suffix = [ss, sd, ps, pd] { def V#prefix#NAME#!toupper(suffix)#rr : Instr< [(set (type regclass:$dst), (type (opcode (type regclass:$src1), (type regclass:$src2))))]>; def V#prefix#N...

Looking around today, it appears that TargetRegisterClass and MCRegisterClass only includes a single alignment. This is documented as being the minimum legal alignment, but it appears to often be greater than this in practice. For instance, on x86 the alignment of %ymm0 is listed as 32, not 1. Does anyone know why this is? Additionally, where are these alignments actually defined? I

...regclass:$dst), (type (opcode (type regclass:$src1), > (type addr:$src2))))]>; > } > } > > multiclass avx_binop<opcode> { > for type = [f32, f64, v4f32, v2f64, v8f32, v4f64] > regclass = [FP32, FP64, VR128, VR128, VR256, VR256] > prefix = [x, x, x, x, y, y] > suffix = [ss, sd, ps, pd] { > > def V#prefix#NAME#!toupper(suffix)#rr : Instr< > [(set (type regclass:$dst), (type (opcode (type regclass:$src1), > (type regclass:$src2))))...

...e regclass:$dst), (type (opcode (type regclass:$src1), >                                                (type addr:$src2))))]>; >  } > } > > multiclass avx_binop<opcode> { >  for type = [f32, f64, v4f32, v2f64, v8f32, v4f64] >      regclass = [FP32, FP64, VR128, VR128, VR256, VR256] >      prefix = [x, x, x, x, y, y] >      suffix = [ss, sd, ps, pd] { > >    def V#prefix#NAME#!toupper(suffix)#rr : Instr< >      [(set (type regclass:$dst), (type (opcode (type regclass:$src1), >                                                (type regclass:$src2))))]...

...pills/reloads of AVX registers using aligned stores/loads? > > Yes. > >> I can't >> seem to find the code that aligns the stack slots to 32-bytes. Could >> someone point me in the right direction? > > The register class has 256-bit spill alignment: > > def VR256 : RegisterClass<"X86", [v32i8, v16i16, v8i32, v4i64, v8f32, v4f64], > 256, (sequence "YMM%u", 0, 15)> { > let SubRegClasses = [(FR32 sub_ss), (FR64 sub_sd), (VR128 sub_xmm)]; > } > > /jakob > > -------------- next part -------...

My purpose is to eliminate copy-paste style of programming in td files as much as possible, but only to a point that the new language constructs do not create too much overhead/readability-downgrade. In other words, I am targeting those low-hanging fruit of copy-paste programmings in td files that are eliminated by a simple for-loop syntax. The repetitive patterns I observed in PTX backend (and

On Jun 15, 2009, at 11:33 AM, David Greene wrote: > To reduce redundancy, developers must be able to write generic > patterns > like this: > > [(set DSTREGCLASS:$dst, // rr, rrr > (xor (INTSRCTYPE (bitconvert (SRCTYPE SRCREGCLASS:$src1))), > (INTSRCTYPE (bitconvert (SRCTYPE SRCREGCLASS:$src2)))))], > > The substitution then fills in the appropriate types,

On Oct 6, 2011, at 12:42 PM, David A. Greene wrote: > Jakob Stoklund Olesen <jolesen at apple.com> writes: > >> On Oct 6, 2011, at 7:59 AM, David A. Greene wrote: >> >>> For example, I want to be able to do this: >>> >>> defm MOVH : >>> vs1x_fps_binary_vv_node_rmonly< >>> 0x16, "movh", undef, 0, >>>

Chris Lattner wrote: > However, I don't see any reason to base this off of strings. Instead > of passing down "f32" as a string, why not do something like this > pseudo code: > > class X86ValueType { > RegisterClass RegClass; > ... > } > > def X86_f32 : X86ValueType { > let RegClass = FR32; > ... }; > def X86_i32 :