search for: v4i64

...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/X86InstrSIMD.td...

On Mon, 25 Jun 2012 05:45:57 +0000 "Rotem, Nadav" <nadav.rotem at intel.com> wrote: > Hi Hal, > > Why do say that the type v4i64 is broken ? You can specify that this > type has no legal operations and the codegen will lower ("legalize") > them to something that works on your platform. For example, the AND operation is really only an AND operation on the sign bits of the underlying floating-point numbers...

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/X86InstrSI...

You could set the AND operation action to custom. The problem is that you would have no way of knowing if the type 'v4i64' originated from v4i1 or v4i64. And I don't think that you can use SimplifyDemandedBits (to discover if only the high bit is set) during the legalizer because the DAG is in a strange state, but I could be mistaken on this one. Okay, here is another idea. There are several DAGCombine in...

...uses the following convention: positive numbers are true, everything else (including NaNs) are false. The outputs of logical operations are -1.0 and 1.0. I am not sure how to best support this in LLVM. LLVM does not have an MVT::v4i1. One thing that I can do (without modifying LLVM core) is to add v4i64 to the vector registers, and pretend that the v4i1 is being promoted to that type (I match loads and stores to pairs of memory operations and fp<->int conversions). This works somewhat (CodeGen will happily generate vectorized selects, comparisons and logical ops on the comparison results), b...

Hi Hal, Why do say that the type v4i64 is broken ? You can specify that this type has no legal operations and the codegen will lower ("legalize") them to something that works on your platform. Nadav -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Hal F...

...bbligato.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/X86Ins...

...call <8 x float> @llvm.x86.avx.blendv.ps.256(<8 x float> %a, <8 x float> %b, <8 x float> %blend_cond) nounwind readnone ret <8 x float> %res } llc (latest trunk) bails out with: LLVM ERROR: Cannot select: 0x2510540: v8f32 = bitcast 0x2532270 [ID=16] 0x2532270: v4i64 = and 0x2532070, 0x2532170 [ID=15] 0x2532070: v4i64 = bitcast 0x2510740 [ID=14] 0x2510740: v8f32 = llvm.x86.avx.cmp.ps.256 0x2510640, 0x2511340, 0x2510f40, 0x2511140 [ORD=3] [ID=12] ... The same counts for or and xor where VXORPS etc. should be selected. There seems to be some code f...

...a bunch of “cannot select" in the LLVM test suite with -march=core-avx-i. E.g., SingleSource/UnitTests/Vector/SSE/sse.isamax.c is failing at O3 -march=core-avx-i with: fatal error: error in backend: Cannot select: 0x7f91b99a6420: v4i32 = bitcast 0x7f91b99b0e10 [ORD=3] [ID=27] 0x7f91b99b0e10: v4i64 = insert_subvector 0x7f91b99a7210, 0x7f91b99a6d68, 0x7f91b99ace70 [ORD=2] [ID=25] 0x7f91b99a7210: v4i64 = undef [ID=15] 0x7f91b99a6d68: v2i64 = scalar_to_vector 0x7f91b99ab840 [ORD=2] [ID=23] 0x7f91b99ab840: i64 = AssertZext 0x7f91b99acc60, 0x7f91b99ac738 [ORD=2] [ID=20] 0x7f9...

...rom 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, (sequence "YMM%u", 0, 31)>; > > Seems to be 256bits/...

...blendv.ps.256(<8 x float> > %a, <8 x float> %b, <8 x float> %blend_cond) nounwind readnone >   ret <8 x float> %res > } > > llc (latest trunk) bails out with: > > LLVM ERROR: Cannot select: 0x2510540: v8f32 = bitcast 0x2532270 [ID=16] >   0x2532270: v4i64 = and 0x2532070, 0x2532170 [ID=15] >     0x2532070: v4i64 = bitcast 0x2510740 [ID=14] >       0x2510740: v8f32 = llvm.x86.avx.cmp.ps.256 0x2510640, 0x2511340, > 0x2510f40, 0x2511140 [ORD=3] [ID=12] > ... > > The same counts for or and xor where VXORPS etc. should be selected. P...

...with >> -march=core-avx-i. >> E.g., SingleSource/UnitTests/Vector/SSE/sse.isamax.c is failing at O3 >> -march=core-avx-i with: >> fatal error: error in backend: Cannot select: 0x7f91b99a6420: v4i32 = >> bitcast 0x7f91b99b0e10 [ORD=3] [ID=27] >> 0x7f91b99b0e10: v4i64 = insert_subvector 0x7f91b99a7210, >> 0x7f91b99a6d68, 0x7f91b99ace70 [ORD=2] [ID=25] >> 0x7f91b99a7210: v4i64 = undef [ID=15] >> 0x7f91b99a6d68: v2i64 = scalar_to_vector 0x7f91b99ab840 [ORD=2] >> [ID=23] >> 0x7f91b99ab840: i64 = AssertZext 0x7f91b99acc60,...

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

Working on a target I added this pattern: def : Pat<(v4i64 (load xoaddr:$src)), (QVFCTIDb (QVLFDXb xoaddr:$src))>; which represents an actual load followed by a necessary conversion operation. The problem is that when this matches any TokenFactor that was attached to the load node gets attached, not to the inner load instruction, but the oute...

...uot; in the LLVM test suite with -march=core-avx-i. >> E.g., SingleSource/UnitTests/Vector/SSE/sse.isamax.c is failing at O3 -march=core-avx-i with: >> fatal error: error in backend: Cannot select: 0x7f91b99a6420: v4i32 = bitcast 0x7f91b99b0e10 [ORD=3] [ID=27] >> 0x7f91b99b0e10: v4i64 = insert_subvector 0x7f91b99a7210, 0x7f91b99a6d68, 0x7f91b99ace70 [ORD=2] [ID=25] >> 0x7f91b99a7210: v4i64 = undef [ID=15] >> 0x7f91b99a6d68: v2i64 = scalar_to_vector 0x7f91b99ab840 [ORD=2] [ID=23] >> 0x7f91b99ab840: i64 = AssertZext 0x7f91b99acc60, 0x7f91b99ac738 [O...

On Sat, 23 Jun 2012 22:28:55 +0100 Tim Northover <t.p.northover at gmail.com> wrote: > On Sat, Jun 23, 2012 at 04:10:51PM -0500, Hal Finkel wrote: > > Working on a target I added this pattern: > > > > def : Pat<(v4i64 (load xoaddr:$src)), > > (QVFCTIDb (QVLFDXb xoaddr:$src))>; > > > > I'd like to fix this so that it works correctly: the TokenFactor > > inputs should be attached to all inner-most instructions. I'm > > guessing this is somewhere in SelectionDAGIS...

...t depends what you're want to do. But I guess you need to model > subreg access properly... Modeling subregisters isn't hard. Do you have some guidance as to when one method is preferable? I am leaning toward using the modifier since conceptually, a vector_extract of element zero on a v4i64 makes sense with AVX (so it is "legal"). You just have to emit the register name as "xmm" rather than "ymm." Why write an additional complicated pattern for this case? -Dave

...e want to do. But I guess you need to model >> subreg access properly... > > Modeling subregisters isn't hard. Do you have some guidance as to when > one method is preferable? I am leaning toward using the modifier since > conceptually, a vector_extract of element zero on a v4i64 makes sense with AVX > (so it is "legal"). You just have to emit the register name as "xmm" rather > than "ymm." Why write an additional complicated pattern for this case? Please don't use asmprinter modifiers. I'm trying to remove them as part of t...

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>

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