search for: v2i64

Hi all. The question about 'load' instruction. When we promote v2i5 = load <addr> ; <MemoryVT = v2i5> to v2i64 = load <addr> ;<MemoryVT = v2i5> should we insert vector shuffling that moves second v2i5 item to the second v2i64 item? Or it is still depends from target? Thanks. -Stepan.

...ed that some of the patterns in X86InstrX86-64.td are wrong. Specifically: def MOV64toPQIrm : RPDI<0x6E, MRMSrcMem, (outs VR128:$dst), (ins i64mem:$src), "mov{d|q}\t{$src, $dst|$dst, $src}", [(set VR128:$dst, (v2i64 (scalar_to_vector (loadi64 addr:$src))))]>; def MOVPQIto64mr : RPDI<0x7E, MRMDestMem, (outs), (ins i64mem:$dst, VR128: $src), "mov{d|q}\t{$src, $dst|$dst, $src}", [(store (i64 (vector_extract (v2i64 VR128:$src),...

...s LowerOperation/LowerBitcast we specifically handle when the source or target type is v2i16 or v4i16, and for other cases we just return the input SDValue and let the "normal" code handle it in whatever way it see fits. In this particular case, when it crashes, we have a bitcast from v2i64 to v4i32: t70: v4i32 = bitcast t27 and t27 is t27: v2i64 = or t15, t26 so it's a bitcast from v2i64 to v4i32 that we don't want to do anything special with so we return the input SDValue which TargetLowering::LowerOperationWrapper returns back to DAGTypeLegalizer::CustomLowerNode an...

...Rather than adding a whole bunch of instruction selection rules to match all the possibilities. We've decided to ask the legalizer to normalize the target-independent nodes to one particular type. See X86ISelLowering.cpp: // Promote v16i8, v8i16, v4i32 load, select, and, or, xor to v2i64. for (unsigned VT = (unsigned)MVT::v16i8; VT != (unsigned) MVT::v2i64; VT++) { setOperationAction(ISD::AND, (MVT::ValueType)VT, Promote); AddPromotedToType (ISD::AND, (MVT::ValueType)VT, MVT::v2i64); ... Evan > > Thanks > -- > Christopher Lamb > >...

Hello. I've tried to add some simple arithmetic vector operations to the BPF backend available in the LLVM repo. Because I added in BPFRegisterInfo.td another RegisterClass (taken from the Mips backend): def MSA128W: RegisterClass<"BPF", [v2i64, v2f64], 128, (sequence "W%u", 0, 31)>; in order to support vector for example, ADD operations, I get the following error when building llc: JEQ_ri: (BPFbrcc i64:i64:$dst, (imm:i64)<<P:Predicate_i64immSExt32>>:$imm, (imm:{i64:v4i32})...

Hi All, I'm working on a back end for an architecture that makes use of multi- typed register classes. def MR: RegisterClass<"namespace", [type1, type2, ... ], ... > When running some preliminary tests I found that the instruction selector refused to select certain ops (specifically stores) for some instructions when the operand type wasn't the first type for the

Hello. I'm having problems at instruction selection with my back end with the following basic-block due to a vector add with immediate constant vector (obtained by vectorizing a simple C program doing vector sum map): vector.ph: ; preds = %vector.memcheck50 %.splatinsert = insertelement <8 x i64> undef, i64 %i.07.unr, i32 0

...pe that equal to original vector type (e.g. v2i5). Or it is a type of memory area for this vector (e.g. v2i8) ? -Stepan. Stepan Dyatkovskiy wrote: > Hi all. The question about 'load' instruction. > When we promote > v2i5 = load<addr> ;<MemoryVT = v2i5> > to > v2i64 = load<addr> ;<MemoryVT = v2i5> > > should we insert vector shuffling that moves second v2i5 item to the > second v2i64 item? > > Or it is still depends from target? > > Thanks. > > -Stepan. > _______________________________________________ > LLVM Devel...

...e form: v <#Elements> <ElementType> it seems logical to use the same scheme for SVE but also incorporate the implicit (VL x) to distinguish from existing vector types. Hence we are proposing each vector MVT have a scalable vector MVT equivalent. MVT::v2i32 -> MVT::nxv2i32 MVT::v2i64 -> MVT::nxv2i64 MVT::v4i32 -> MVT::nxv4i32 MVT::v4i64 -> MVT::nxv4i64 ....likewise for all <#Elements> and <ElementType> combinations The resulting SVE instruction selection is... (1) Pat<(nxv2i64 (add (nxv2i64 $zn), (nxv2i64 $zm))), ADD_D_ZZZ // New SVE pattern (2) Pa...

Hi all, How do I generate the movq2dq SSE2 instruction using the IRBuilder? There is no zext from 64-bit to 128-bit (corresponding to MMX to XMM register transfer) as far as I can tell. So I've tried inserting an i64 into a v2i64, which generates valid code but rather a number of stores and loads on the stack instead of a single movq2dq. Looking though the code, I found a pattern for the instruction in X86GenDAGISEL.inc, but it describes a i64 to v2i64 bitcast (which isn't allowed by IRBuilder). Also, it is describe...

.... v2i5). Or it is a type of memory > area for this vector (e.g. v2i8) ? > > -Stepan. > > Stepan Dyatkovskiy wrote: >> Hi all. The question about 'load' instruction. >> When we promote >> v2i5 = load<addr> ;<MemoryVT = v2i5> >> to >> v2i64 = load<addr> ;<MemoryVT = v2i5> >> >> should we insert vector shuffling that moves second v2i5 item to the >> second v2i64 item? >> >> Or it is still depends from target? >> >> Thanks. >> >> -Stepan. >> ______________________...

...result vector types are the same), then we can just convert this to (op %a [, %b]) Which is likely going to produce better code in all cases. Of course, things like this have a tendency to not be better in all cases, but I think we can probably account for any corner cases that arise. Example: (v2i64 build_vector (mulhs (extractelt %a, 0), (extractelt %b, 0)), (mulhs (extractelt %a, 1), (extractelt %b, 1))) Can be converted to the following on a target that has the operation available on vectors. (v2i64 mulhs %a, %b) A further improvement might be if the order of extracted...

Hello Hal, > MultiSource/Applications/ClamAV - fails to compile shared_sha256.c with > an error: error in backend: Cannot select: 0x4fbcb40: v2i64 = > X86ISD::MOVLPD 0x4149e00, 0x418d930 [ID=596] Please report this as a PR regardless of the pass. Bugs in the backend should be fixed. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hi AArch64 experts - I'm working on a DAGCombiner patch, and it causes a change in an existing regression test. We're generating this: ext v0.16b, v1.16b, v1.16b, #8 Rather than this: mov d0, v1.d[1] Are those logically equivalent? Is one form preferred over the other? This is the IR test case in /test/CodeGen/AArch64/neon-scalar-copy.ll: define <1 x i64>

Hi All, Can I change a vector load to gather intrinsic? If so, how can I do it? For example, I want to change the following IR code %1 = load <2 x i64>* %arrayidx1, align 8 to %1 = call <2 x i64> @llvm.masked.gather.v2i64(<2 x i64*> %arrayidx1, i32 8, <2 x i1> <i1 true, i1 true>, <2 x i64> undef) Basically, I am not sure how to get two consecutive addresses started from arrayidx1. Thanks for your time and help in advance. Best, Zhi -------------- next part -------------- An HTML attachment...

...imagine that you are not expecting other LLVM optimizations to > interact with them right ? (it looks that way from this example[1]). If you > are not accessing the individual components then you can use i128, or even <2 > x i64>. We have put some effort into trying to use i128 or v2i64, but it seems that post instruction selection LLVM is incredibly keen on putting values of those types in their 'correct' register class (e.g. XMM) in preference to the BNDx bounds registers. I haven't found any workaround for that, and adding an MVT code (where there is already precede...

...considered opaque, > that is, not useful outside of the specific instructions using this > register class. > > After much experimentation, I think it's necessary to model this in > the backend with a new MVT code (ValueTypes.h). Trying to fake it > with an existing type (e.g. v2i64 or i128) leads to these registers > being misused for other values and vice versa. > > We want to have intrinsics map to some of these instructions (both > IR and C, in the usual <*intrin.h> form). I'm trying to avoid > having the added MVT escape the code generator by usi...

...ft = lshr <2 x i128> %mul, <i128 64, i128 64> %trunc = trunc <2 x i128> %shift to <2 x i64> ret <2 x i64> %trunc } On PPC, the legalizer will scalarize this since we do not have v2i128. Then the DAG combiner will produce the pattern I am referring to in this RFC: (v2i64 build_vector (mulhs (extractelt %a, 0), (extractelt %b, 0)), (mulhs (extractelt %a, 1), (extractelt %b, 1))) And if the target has mulhs legal for the vector type, this is strictly worse. So no matter what we do in InstCombine or the SLP vectorizer, we will end up with non-opti...

...The two 64-bit values can be considered opaque, that is, not useful outside of the specific instructions using this register class. After much experimentation, I think it's necessary to model this in the backend with a new MVT code (ValueTypes.h). Trying to fake it with an existing type (e.g. v2i64 or i128) leads to these registers being misused for other values and vice versa. We want to have intrinsics map to some of these instructions (both IR and C, in the usual <*intrin.h> form). I'm trying to avoid having the added MVT escape the code generator by using some other type repres...

...ced all occurrences: > PatLeaf<(imm) > %(which were ambiguous since the variable name ("in dag operator") does not have a > type and this poses issues to the Type inference algorithm, since I added in > ConnexRegisterInfo.td a second RegisterClass with type v2i64) > with > PatLeaf<(i64 imm) > namely: > - def i64immSExt32 : PatLeaf<(i64 imm), > [{return isInt<32>(N->getSExtValue()); }]>; > > Best regards, > Alex > > On 1/8/2016 1:31 AM, RCU wrote: >>...