search for: v8i1

Help: How to define vector element type bool (v8i1) in C builtin function hello everyone,I have defined intrinsic function like this: def int_mips_add_32 : GCCBuiltin<"__builtin_dongxin_add_32">, Intrinsic<[llvm_v4i32_ty], [llvm_v4i32_ty, llvm_v4i32_ty,llvm_v8i1_ty]>; Then I write a test code : typedef int v4i32 __attribut...

Subject: How to define vector element type bool in builtin function hello everyone,I have defined intrinsic function like this: def int_mips_add_32 : GCCBuiltin<"__builtin_dongxin_add_32">, Intrinsic<[llvm_v4i32_ty], [llvm_v4i32_ty, llvm_v4i32_ty,llvm_v8i1_ty]>; Then I write a test code : typedef int v4i32 __attribute__ ((vector_size(16))); typedef bool v8i1 __attribute__ ((vector_size(1))); void foo() { v4i32 v4i32_r1,v4i32_r2,v4i32_r3; v8i1 vm_1; v4i32_r1 = __builtin_dongxin_add_32(v4i32_r2,v4i32_r2,vm_1); } but when I compi...

...EVT BitcastVT) const { > + if (!LoadVT.isVector() && BitcastVT.isVector() && > + BitcastVT.getVectorElementType() == MVT::i1 && > + !Subtarget.hasAVX512()) > + return false; > + > if (!Subtarget.hasDQI() && BitcastVT == MVT::v8i1) > return false; > > > ~Craig > > > On Mon, Nov 26, 2018 at 2:51 PM Johan Engelen via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> I've run into a case where the optimizer seems to be having trouble >> doing the "...

Hi all, I've run into a case where the optimizer seems to be having trouble doing the "obvious" thing. Consider this code: ``` define i16 @foo(<8 x i16>* dereferenceable(16) %egress, <16 x i8> %a0) { %a1 = icmp slt <16 x i8> %a0, zeroinitializer %a2 = bitcast <16 x i1> %a1 to i16 %astore = getelementptr inbounds <8 x i16>, <8 x i16>*

...ael.haidl at uni-muenster.de > <mailto:michael.haidl at uni-muenster.de>> wrote: > > Hi Renato, > > just to make it clear, I didn't implement reductions on x86_64 they just > worked when I tried to lower an > llvm.experimentel.vector.reduce.or.i1.v8i1 intrinsic. A shuffle pattern > is generated for the intrinsic. > > vpshufd $78, %xmm0, %xmm1 # xmm1 = xmm0[2,3,0,1] > vpor %xmm1, %xmm0, %xmm0 > vpshufd $229, %xmm0, %xmm1 # xmm1 = xmm0[1,1,2,3] > vpor %xmm1...

This post is related to the following post http://lists.llvm.org/pipermail/llvm-dev/2016-April/098823.html I'm still trying to compile a library with clang. But now I'm getting as assert in lib/CodeGen/TargetLoweringBase.cpp:1155: virtual llvm::EVT llvm::TargetLoweringBase::getSetCCResultType(llvm::LLVMContext&, llvm::EVT) const: Assertion `!VT.isVector() && "No default

...ster.de>>> wrote: > > > > Hi Renato, > > > > just to make it clear, I didn't implement reductions on > x86_64 they just > > worked when I tried to lower an > > llvm.experimentel.vector.reduce.or.i1.v8i1 intrinsic. A > shuffle pattern > > is generated for the intrinsic. > > > > vpshufd $78, %xmm0, %xmm1 # xmm1 = xmm0[2,3,0,1] > > vpor %xmm1, %xmm0, %xmm0 > > vpshufd $229, %xmm0, %xmm1...

...6_avx512_gather_dps_mask_512 : >GCCBuiltin<"__builtin_ia32_mask_gatherdps512">, > Intrinsic<[llvm_v16f32_ty], [llvm_v16f32_ty, llvm_i16_ty, > llvm_v16i32_ty, llvm_ptr_ty, llvm_i32_ty], > [IntrReadMem]>; I expected a v8i1/v16i1 for the gather intrinsics. Is there a reason for this type difference or is it just an oversight? This is the case for the compare, gather, scatter, and blend intrinsics. Also, please note that the current implementation is functionally correct. During ISelLowering, a bitcast is inserted to...

...e major changes and decided that this is not the way to go. _Packed_ I followed Duncan’s original suggestion which was packing vectors of i1s into general purpose registers. I started by adding several new types to ValueTypes (td and h).  I added ‘4vi1, 8vi1, 16vi1 … 64vi1’.  For x86, I mapped the v8i1 .. v8i64 to general purpose x86 registers. I started playing with a small program, which performed a vector CMP on 4 elements. The legalizer promoted the v4i1 to the next legal pow-of-two type, which was v8i1. I changed WidenVecRes_SETCC and added a new method WidenVecOp_Select to handle the legal...

...86 targets), optimal representation of the result of compare is determined by how it is consumed, and it is not a good idea to have such optimization in multiple different places. If the legalizer has to blindly legalize v4i1 without knowing how it is consumed, it is best to look at what happens to v8i1. We can then let the same optimizer work to get the optimal ASM code out in the end, whether vectorization factor is 4 or 8. In the end, I may be agreeing to Rob, but not because of the reasons Rob mentioned. One of the headaches is movmskps/pmovmskb do not have a quick reverse instruction (MIC-AV...

Hi Amara, thank you for the clarification. I tested the intrinsics x86_64 and it seemed to work pretty well. Looking forward to try this intrinsics with the AArch64 backend. Maybe I find the time to look into codegen to get this intrinsics out of experimental stage. They seem pretty useful. Cheers, Michael -----Original Message----- From: Amara Emerson [amara.emerson at gmail.com] Received:

...; %evl = call @llvm.vscale() ; AVX: ; %mask = icmp (%i + (seq <8 x i32> 0,1,2,.,)), %n, ; %evl = i32 8 Unless I miss something, the AVX example is semantically the same as get.active.lane.mask: %m[i] = icmp ult (%base + i), %n with i = 8. Correct (llvm.get.active.lane.mask.v8i1.i32). Just saying this to see if we can have "1 interface" for generating the mask (which is what I was perhaps expecting), and if you just want an all true mask for VE and if we can merge AVX with the other 2 we just have: ; RISC-V V & VE(*): ; %mask = get.active.lane.mask(%i,...

Hello, I'm working on support for the SIMD instruction set on our new BG/Q supercomputer. This instruction set is v4f64 (with the exception of some int <-> fp conversions, floating-point only). The vectorized comparisons, logical operations and selects also exclusively use floating-point inputs. For those inputs that are logically vectors of booleans the system uses the following

...; %evl = call @llvm.vscale() ; AVX: ; %mask = icmp (%i + (seq <8 x i32> 0,1,2,.,)), %n, ; %evl = i32 8 Unless I miss something, the AVX example is semantically the same as get.active.lane.mask: %m[i] = icmp ult (%base + i), %n with i = 8. Correct (llvm.get.active.lane.mask.v8i1.i32). Just saying this to see if we can have "1 interface" for generating the mask (which is what I was perhaps expecting), and if you just want an all true mask for VE and if we can merge AVX with the other 2 we just have: ; RISC-V V & VE(*): ; %mask = get.active.lane.mask(%i,...

On 11/6/20 8:49 AM, Roger Ferrer Ibáñez wrote: Hi Sjoerd, Trying to remember how everything fits together here, but could get.active.lane.mask not create the %mask of the VP intrinsics? Or in other words, in the vectoriser, who's producing the %mask and %evl that is consumed by the VP intrinsics? I'm not sure what would be the best way here. I think about the Loop Vectorizer. I imagine

...ets. It is also worth noting that the legality of a type 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...