search for: v8i8

Hi all, I am working on a target that has support for v4i16 vectors, and no support for v4i8 / v8i8 / v8i16 V4i8 is promoted to v4i16 which is nice V8i16 is split to 2 x v4i16 which is nice as well Now v8i8 is scalarized, which is not so nice. Ideally I would like v8i8 to be first promoted to v8i16 then split to 2xv4i16 (or split to 2xV4i8 then promoted to 2xv4i16) Is there a way to achieve th...

...eper reason? While cleaning up PMOV*X patterns, I stumbled upon this braindead testcase: %0 = load <8 x i8>* %src, align 1 %1 = zext <8 x i8> %0 to <8 x i16> turning into: pmovzxbw (%rsi), %xmm0 pand <0xff,0xff,...>, %xmm0, %xmm0 v8i8 isn't legal, so the load became an anyext load from v8i8 to v8i16, with the pand masking out the unwanted/zero bits. In that example, if you declare zextloads from v8i8 legal, and add the simple corresponding pattern, the pand isn't generated anymore, as expected. So, unless I'm missi...

...sp:$Rm, (i64 3)), (add (mulB<ldop> GPR64sp:$Rn, GPR64sp:$Rm, (i64 2)), (add (mulB<ldop> GPR64sp:$Rn, GPR64sp:$Rm, (i64 1)), (mulBz<ldop> GPR64sp:$Rn, GPR64sp:$Rm))))), (EXTRACT_SUBREG (i64 (DOT (DUPv2i32gpr WZR), (v8i8 (LD1Onev8b GPR64sp:$Rn)), (v8i8 (LD1Onev8b GPR64sp:$Rm)))), sub_32)>, Requires<[HasDotProd]>; def : DotProductI32<SDOTv8i8, sextloadi8>; def : DotProductI32<UDOTv8i8, zextloadi8>; Then when I extended it to 8 element vectors, the time spent by tblg...

...to work correctly, but then it fails instruction selection because of Other. I have not been able to figure out how to split the MVT::Other node yet, any idea how to do this? Instruction selection fails because it cannot match the pattern: v4i8 = sign_extend_inreg <v4i8 node>, <Other node(v8i8 VTSDNode)> The reason being my initial implementation based on the advice given takes as input: v8i8 = sign_extend_inreg <v8i8 node>, <Other node(v8i8 VTSDNode)> and generates two: v4i8 = sign_extend_inreg <v4i8 node>, <Other node(v8i8 VTSDNode)> Instead it should gener...

Thanks Eli, I'll see if I can get something working and submit a patch. Micah -----Original Message----- From: Eli Friedman [mailto:eli.friedman at gmail.com] Sent: Wednesday, December 09, 2009 11:18 PM To: Villmow, Micah Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] SplitVecRes with SIGN_EXTEND_INREG unsupported On Wed, Dec 9, 2009 at 8:40 PM, Villmow, Micah <Micah.Villmow at

...at, since the verifier is not checking its type, many intrinsics > actually has the wrong type definition. For example, int_aarch_neon_st2 is > defined as (llvm_anyvector_ty, LLVMMatchType<0>, > LLVMAnyPointerType<LLVMMatchType<0>>), but in reality, it has type like > (v8i8, v8i8, i8*) instead of (v8i8, v8i8, v8i8*). I write up a patch myself > to check all types in LLVMAnyPointerType and many regression tests failed. > I cannot find a way to fix all the testcase failures without breaking the > bitcode compatibility. I currently generate all of the variation...

...his operation looks very high. Wondering why such a high cost kept for this, any pointers to understand this will be helpful. In few cases this restricts better vectorization opportunities. Other observations: Cost for TRUNCATE v16i32 to v16i8 in SSE2ConversionTbl as 7. Cost for TRUNCATE v8i32 to v8i8 is 2 in AVX2 and 4 in AVX mode. Thanks, Ashutosh -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160411/7233218b/attachment.html>

> On Sep 19, 2014, at 9:57 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > > So the proposal is that during development new features are added to > test/Features/compatibility.ll (or some other name). When 3.6 is > released, we will > > * assemble the file with llvm-as-3.6. > * Check in the .bc file as test/Features/Input/compatibility-3.6.bc > *

...of Rt2 (i.e. 'b' from R1 + 'a' from R2, because R1.aba'b' and R2.bba'a') will be lost, too. I don't know whether I can set the 'type' of such register using a llvm::MVT::SimpleValueType? According the LLVM doc & LLVM source codes, I think llvm::MVT::v8i8, v2f32, etc is used to represent register for SIMD instructions. I don't think the operations in my platform are SIMD instructions. However, I can not find any llvm::MVT::SimpleValueType which can represents a 96-bit register. Thus, my question is: 1) Does current LLVM backend supports this H...

...32_, though the comment says GR32_ is only for 32 bit mode, so it's not _really_ the case that it's in multiple classes). Does ValueType have something to do with that? In the same file, the VR64 register class has the following definition: def VR64 : RegisterClass<"X86", [v8i8, v4i16, v2i32, v1i64], 64, [MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7]>; So there are multiple ValueTypes here (the scalar registers each only have one corresponding to the bit size of the register). But still, if I have physical register MM2, that completely determines...

...his operation looks very high. Wondering why such a high cost kept for this, any pointers to understand this will be helpful. In few cases this restricts better vectorization opportunities. Other observations: Cost for TRUNCATE v16i32 to v16i8 in SSE2ConversionTbl as 7. Cost for TRUNCATE v8i32 to v8i8 is 2 in AVX2 and 4 in AVX mode. Thanks, Ashutosh --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others...

...  > > from R2, because R1.aba'b' and R2.bba'a') will be lost, too. > > > I don't know whether I can set the 'type' of such register using a   > > llvm::MVT::SimpleValueType? > > According the LLVM doc & LLVM source codes, I think llvm::MVT::v8i8,   > > v2f32, etc is used to represent register for SIMD instructions. > > I don't think the operations in my platform are SIMD instructions. > > However, I can not find any llvm::MVT::SimpleValueType which can   > > represents a 96-bit register. > > > Thus, my...

...om R1 + 'a' > from R2, because R1.aba'b' and R2.bba'a') will be lost, too. > > I don't know whether I can set the 'type' of such register using a > llvm::MVT::SimpleValueType? > According the LLVM doc & LLVM source codes, I think llvm::MVT::v8i8, > v2f32, etc is used to represent register for SIMD instructions. > I don't think the operations in my platform are SIMD instructions. > However, I can not find any llvm::MVT::SimpleValueType which can > represents a 96-bit register. > > Thus, my question is: > > 1)...

...// IntSelect VarSpillAlignment // } To fully implement the AddReg instruction, the target would then define the register class: class MyRegisterClass : RegisterClass<...> { let VarRegTypes = ValueTypeListSelect<[Mode64, Mode128], [[i64, v2i32, v4i16, v8i8], // Mode64 [i128, v2i64, v4i32, v8i16, v16i8]]>; // Mode128 let VarRegSize = IntSelect<[Mode64, Mode128], [64, 128]>; let VarSpillSize = IntSelect<[Mode64, Mode128], [64, 128]>; let VarSpillAlignment = IntSelect<[Mode64, Mode128], [64, 12...

How do I get the TargetRegisterClass for a physical register? SSARegMap::getRegClass only works for virtual registers. -Dave

Take a look at getPhysicalRegisterRegClass( const MRegisterInfo *MRI, MVT::ValueType VT, unsigned reg) in ScheduleDAG.cpp. -- Christopher Lamb On Jun 18, 2007, at 4:52 PM, David A. Greene wrote: > How do I get the TargetRegisterClass for a physical register? > SSARegMap::getRegClass only works for virtual registers. > >

...from R2, because R1.aba'b' and R2.bba'a') will be lost, too. >> >>> I don't know whether I can set the 'type' of such register using a >>> llvm::MVT::SimpleValueType? >>> According the LLVM doc & LLVM source codes, I think llvm::MVT::v8i8, >>> v2f32, etc is used to represent register for SIMD instructions. >>> I don't think the operations in my platform are SIMD instructions. >>> However, I can not find any llvm::MVT::SimpleValueType which can >>> represents a 96-bit register. >> >&gt...

Hi All, If the target supports quad-register R0:R1:R2:R3 (Rn is 32-bit register), is it possible mapping quad-register to v4i32 so that the following example work? typedef int v4si __attribute__ ((vector_size (16))); void foo(v4si i) { v4si j = i; } I don't know how to write CallingConv.td to represent the concept of occupying quad-register R0:R1:R2:R3 once seeing

...from R2, because R1.aba'b' and R2.bba'a') will be lost, too. >> >>> I don't know whether I can set the 'type' of such register using a >>> llvm::MVT::SimpleValueType? >>> According the LLVM doc & LLVM source codes, I think llvm::MVT::v8i8, >>> v2f32, etc is used to represent register for SIMD instructions. >>> I don't think the operations in my platform are SIMD instructions. >>> However, I can not find any llvm::MVT::SimpleValueType which can >>> represents a 96-bit register. >> >&gt...

...|| getOperationAction(Op, NVT) == Promote); The first line in the do while loop is important, it just increments the type, starting at MVT::v4i8 until it hits a legal type. This seems broken to me. Here is what TOT LLVM has for its MVT list: v4i8 = 14, // 4 x i8 v8i8 = 15, // 8 x i8 v16i8 = 16, // 16 x i8 v32i8 = 17, // 32 x i8 v2i16 = 18, // 2 x i16 v4i16 = 19, // 4 x i16 v8i16 = 20, // 8 x i16 v16i16 = 21, // 16 x i16 v2i32...