search for: v1i16

...uimm2:$rshift), &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; !strconcat(opcodestr, ""), "$rs1, [$rbase + ( $roffset << $rshift )]", &nbsp; //&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [(OpNode v1i16:$rs1, (add (v1i32 (bitconvert i32:$rbase)), (shl&nbsp; (v1i32 (sext v1i16:$roffset)), (v1i32 (build_vector uimm2:$rshift)) )))]&gt;; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;[(OpNode (v1i16 $rs1), (add (v1i32 (bitconvert (i32 $rbase))), (shl&amp...

...rk/rpp_clang/llvm/utils/TableGen/TableGen.cpp:253:0 #27 0x00007f163fa21830 __libc_start_main /build/glibc-LK5gWL/glibc-2.23/csu/../csu/libc-start.c:325:0 #28 0x0000000000407bd9 _start (../../../bin/llvm-tblgen+0x407bd9) =========================================================== PATTERN: (st v1i16:{ *:[v1i16] }:$rs1, (add:{ *:[v1i32] } (shl:{ *:[v1i32] } (sext:{ *:[v1i32] } v1i16:{ *:[v1i16] }:$roffset), (build_vector:{ *:[v1i32] } (imm:{ *:[i32] })<<P:Predicate_uimm2&gt;&gt;:$rshift)), (bitconvert:{ *:[v1i32] } i32:{ *:[i32] }:$rbase)))<<P:Predicate_unindexedstore&gt...

...e = "RPP"; &nbsp; dag OutOperandList = (outs); &nbsp; dag InOperandList = (ins MGPR:$rs1, SGPR32:$rbase, MGPR:$roffset, uimm2:$rshift); &nbsp; string AsmString = "STORE $rs1, [$rbase + ( $roffset << $rshift )]"; &nbsp; list<dag&gt; Pattern = [(store (v1i16 ?:$rs1), (add (v1i32 (bitconvert (i32 ?:$rbase))), (shl (v1i32 (sext (v1i16 ?:$roffset))), (v1i32 (build_vector (uimm2 ?:$rshift))))))]; &nbsp; list<Register&gt; Uses = []; &nbsp; list<Register&gt; Defs = []; &nbsp; int CodeSize = 0; &nbsp; int AddedComplexity = 0; &am...

...es, e.g. MGPR:$rs1.&nbsp; In the pattern they don’t have them.&nbsp; The error you saw (“rs1 must be an identifier”) was caused by tablegen being unable to match the rs1 in the pattern with any of the instruction operands. Could you change the pattern to &nbsp; &nbsp; [(OpNode (v1i16 MGPR:$rs1), (add (v1i32 (bitconvert (i32 SGPR32:$rbase))), (shl&nbsp; (v1i32 (sext (v1i16 MGPR:$roffset))), (v1i32 (build_vector (i32 uimm2:$rshift))) )))] &nbsp; -- Krzysztof Parzyszek kparzysz at quicinc.com&nbsp;&nbsp; AI tools development &nbsp; From: Celine...

I think that you attached the wrong patch. The attached patch is the one which adds the new MVT types. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Villmow, Micah Sent: Saturday, July 28, 2012 01:54 To: Developers Mailing List Subject: [LLVMdev] Vector promotion broken for <2 x [i8|i16]> Vector promotion which is new in LLVM 3.1 is broken for

Vector promotion which is new in LLVM 3.1 is broken for sub32 bit types. The problem is in the VectorLegalizer::PromoteVectorOp. The function getTypeToPromoteTo will return a <2 x i32> for a <2 x i8>, <2 x i16> or <4 x i8>. The problem is that there are no vectors of size 1 defined for i32 or i16. The attached patch fixes these issues. This can be reproduced by setting in

No, that is correct. I am adding the new types so that I can bitcast v2i8 into a v1i16 and then perform the 'and' operation and have legalize types turn the v1i16 into a scalar. Though I am having trouble in understanding how x86 supports the <1 x i64> type. Based on looking at the code, it should fail because v1i64 is not supported on the x86 platform as far as I can...

...= 20, // 8 x i16 v16i16 = 21, // 16 x i16 v2i32 = 22, // 2 x i32 So, for my platform with the 'and' I promote all i8 and i16 types, so the first type that is legal is v2i32. If I add the v1i32 then it works, however, it breaks when I added v1i16(which I need for the v2i8 case). So I set AddPromotedType(ISD::AND, MVT::v4i8, MVT::v1i32) to get around it. So it seems in this case someone has hit this issue before and added the ability to override promotion rules. > -----Original Message----- > From: Rotem, Nadav [mailto:nadav.rotem at...

...= 20, // 8 x i16 v16i16 = 21, // 16 x i16 v2i32 = 22, // 2 x i32 So, for my platform with the 'and' I promote all i8 and i16 types, so the first type that is legal is v2i32. If I add the v1i32 then it works, however, it breaks when I added v1i16(which I need for the v2i8 case). So I set AddPromotedType(ISD::AND, MVT::v4i8, MVT::v1i32) to get around it. So it seems in this case someone has hit this issue before and added the ability to override promotion rules. > -----Original Message----- > From: Rotem, Nadav [mailto:nadav.rotem at...

...v16i16 = 21, // 16 x i16 > v2i32 = 22, // 2 x i32 > > So, for my platform with the 'and' I promote all i8 and i16 types, so > the first type that is legal is v2i32. > > If I add the v1i32 then it works, however, it breaks when I added > v1i16(which I need for the v2i8 case). > > So I set AddPromotedType(ISD::AND, MVT::v4i8, MVT::v1i32) to get around > it. So it seems in this case someone has hit this issue before and > added the ability to override promotion rules. > > > -----Original Message----- > > From:...

...v16i16 = 21, // 16 x i16 > v2i32 = 22, // 2 x i32 > > So, for my platform with the 'and' I promote all i8 and i16 types, so > the first type that is legal is v2i32. > > If I add the v1i32 then it works, however, it breaks when I added > v1i16(which I need for the v2i8 case). > > So I set AddPromotedType(ISD::AND, MVT::v4i8, MVT::v1i32) to get > around it. So it seems in this case someone has hit this issue before > and added the ability to override promotion rules. > > > -----Original Message----- > > From...

Hi, We are now about halfway between the 3.4 and 3.5 releases, and I would like to start preparing for a 3.4.1 release. Here is my proposed release schedule: Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4 branch. April 9 - April 18: Testing Phase April 18: 3.4.1 Release How you can help: - If you have any bug fixes you think should be included to 3.4.1, send me an

I don't know how your target architecture looks like, but I suspect that <4 x i8> should not be legalized to <1 x i32>. I think that what you are seeing is that <4 x i8> is first split into <2 x i8>, and later promoted to <2 x i32>. At the moment different targets can only affect type-legalization by declaring different legal types. A number of us discussed the

Sorry, <4 x i8> should convert to a <1 x i32>. What currently is happening is that it is returning a <2 x i32> because <1 x i32> does not exist. Micah > -----Original Message----- > From: Rotem, Nadav [mailto:nadav.rotem at intel.com] > Sent: Monday, July 30, 2012 10:51 AM > To: Villmow, Micah; Developers Mailing List > Subject: RE: Vector promotion broken

...is a function of the type's bit size only. In other words, if f64 is a legal type, so is i64, v2f32, and even v64i1. On the ARM target, for example, these types would be legal: All 8-bit types via ldrb/strb to GPR. (i8, v1i8, v2i4, v4i2, v8i1) All 16-bit types via ldrh/strh to GPR. (i16, f16, v1i16, v2i8, ...) All 32-bit types via ldr/str to GPR and vldr/vstr to SPR. All 64-bit types via ldrd/strd to GPRPair and vldr/vstr to DPR. All 128-bit types via vld1/vst1 to DPair. All 192-bit types via vld1/vst1 to DTriple. All 256-bit types via vld1/vst1 to DQuad. This larger set of legal types also m...