search for: v4f64

...> > 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/32bytes. Yeah,...

...eclare ppc_c128 @llvm.cconj.ppc_c128(ppc_c128 %val) llvm.czip.* - Overloaded intrinsic to create a vector of complex from two vectors of floating-point type (not all variants shown) declare v4c32 @llvm.czip.v4c32(v4f32 %real, v4f32 %imag) declare v4c64 @llvm.czip.v4c32(v4f64 %real, v4f64 %imag) llvm.extractreal.* - Overloaded intrinsic to create a vector of floating-point type from the real portions of a vector of complex (not all variants shown) declare v4f32 @llvm.extractreal.v4c32(v4c32 %val) declare v4f64 @llvm.extractrea...

...adedVect = DAG.getNode <http://llvm.org/docs/doxygen/html/classllvm_1_1SelectionDAG.html#ab02868bea897db34232413f1929ade1d> (ISD::INTRINSIC_WO_CHAIN <http://llvm.org/docs/doxygen/html/namespacellvm_1_1ISD.html#a22ea9cec080dd5f4f47ba234c2f59110ac771b9cda3b889242d457cc4d9b2159c>, dl, MVT::v4f64, DAG.getConstant <http://llvm.org/docs/doxygen/html/classllvm_1_1SelectionDAG.html#adf7343dcb7fff67cf516abca4c1d6793>(Intrinsic::ppc_qpx_qvfcfidu, dl, MVT::i32), LoadedVect); Something like this? On Tue, Feb 2, 2016 at 12:55 PM, Matt Arsenault <arsenm2 at gmail.com> wrote:...

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

...LVM ERROR: Cannot select: 0x14214bb10: i16 = extract_vector_elt 0x14214b910, 0x142142c10 14116 - Inliner incorrectly combines cleanup and catch landing pads 14279 - mishandling of implicit move in class with copy-only member 14337 - UNREACHABLE executed at CallingConvLower.cpp:111 when returning v4f64 on ARM 14429 - Dragonegg fails to build clang Pawel

...).SimpleTy)) & 3); assert(Action != Promote && "Can't promote condition code!"); return Action; } The first part of the assertion I can understand, but why is there an assertion that there are only 32 types? in TOT LLVM if this code is called with v8f32,v2f64 or v4f64, this assert is triggered. Shouldn't the assert be: (unsigned)VT.getSimpleVT().SimpleTy < MVT::MAX_ALLOWED_VALUETYPE && or (unsigned)VT.getSimpleVT().SimpleTy < MVT::LAST_VECTOR_VALUETYPE && ? Thanks, Micah -------------- next part -------------- An HTML attachment was...

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>

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

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 convention: positive numbers a...

...>> llvm.extractreal.* - Overloaded intrinsic to create a vector of >> floating-point type from the real portions of a >> vector of complex (not all variants shown) >> >> declare v4f32 @llvm.extractreal.v4c32(v4c32 %val) declare v4f64 >> @llvm.extractreal.v4c64(v4c64 %val) >> >> llvm.extractimag.* - Overloaded intrinsic to create a vector of >> floating-point type from the imaginary portions >> of a vector of complex (not all variants shown) >> >&gt...

Hi Bruno, > Some comments: > > + // Try to synthesize horizontal adds from adds of shuffles. > + if (((Subtarget->hasSSE3()&& (VT == MVT::v4f32 || VT == MVT::v2f64)) || > + (Subtarget->hasAVX()&& (VT == MVT::v8f32 || VT == MVT::v4f64)))&& > + isHorizontalBinOp(LHS, RHS, true)) > > 1) You probably want to do something like: > > "bool HasHorizontalArith = Subtarget->hasSSE3() || > Subtarget->hasAVX()" and check it for the first condition, because > when AVX is on, the SSE levels a...

I 100% get that we might not like the decisions clang-format is making, but how does one overcome this when adding new code? The pre-merge checks enforce clang-formatting before commit and that's a common review comment anyway for those who didn't join the pre-merge checking group. I'm just wondering are we not all following the same guidelines? Concerns of clang-format not being good

...ert(Action != Promote && "Can't promote condition code!"); > return Action; > } > > The first part of the assertion I can understand, but why is there an > assertion that there are only 32 types? in TOT LLVM if this code is > called with v8f32,v2f64 or v4f64, this assert is triggered. > Shouldn't the assert be: > (unsigned)VT.getSimpleVT().SimpleTy < MVT::MAX_ALLOWED_VALUETYPE && > or > (unsigned)VT.getSimpleVT().SimpleTy < MVT::LAST_VECTOR_VALUETYPE && > ? > > Thanks, > Micah > > -- Hal Fi...

...: i16 = > extract_vector_elt 0x14214b910, 0x142142c10 > > 14116 - Inliner incorrectly combines cleanup and catch landing pads > > 14279 - mishandling of implicit move in class with copy-only member > > 14337 - UNREACHABLE executed at CallingConvLower.cpp:111 when returning > v4f64 on ARM > > 14429 - Dragonegg fails to build clang > > > Pawel > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > --------------...

...c.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Hal Finkel Sent: Monday, June 25, 2012 06:28 To: LLVM Developers Mailing List Subject: [LLVMdev] Boolean floats and v4i1 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 convention: positive numbers a...

...I should be doing the tablegen bits. This is awesome :D Some comments: + // Try to synthesize horizontal adds from adds of shuffles. + if (((Subtarget->hasSSE3() && (VT == MVT::v4f32 || VT == MVT::v2f64)) || + (Subtarget->hasAVX() && (VT == MVT::v8f32 || VT == MVT::v4f64))) && + isHorizontalBinOp(LHS, RHS, true)) 1) You probably want to do something like: "bool HasHorizontalArith = Subtarget->hasSSE3() || Subtarget->hasAVX()" and check it for the first condition, because when AVX is on, the SSE levels are all turned off (as to conside...

...l, I am current working with SIMD instruction along with stackmap features. Recently I encountered a problem involving legalizing stackmap. In my stackmap, I record all the live values existing at the callsite. One of the operands in my stackmap is an illegal vector type for arm64 architecture ( *v4f64*) and requires vector splitting in order to legalize the node ( *v2f64*). However, I noticed that in the *DAGTypeLegalizer::SplitVectorOperand* function, the switch case does not handle stackmap cases. So initially every time I run my code with *-mllvm -debug-only=legalize_types* I will get an...

...elt 0x14214b910, 0x142142c10 >> >> 14116 - Inliner incorrectly combines cleanup and catch landing pads >> >> 14279 - mishandling of implicit move in class with copy-only member >> >> 14337 - UNREACHABLE executed at CallingConvLower.cpp:111 when returning >> v4f64 on ARM >> >> 14429 - Dragonegg fails to build clang >> >> >> Pawel >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/l...

...).SimpleTy)) & 3); assert(Action != Promote && "Can't promote condition code!"); return Action; } The first part of the assertion I can understand, but why is there an assertion that there are only 32 types? in TOT LLVM if this code is called with v8f32,v2f64 or v4f64, this assert is triggered. Shouldn't the assert be: (unsigned)VT.getSimpleVT().SimpleTy < MVT::MAX_ALLOWED_VALUETYPE && or (unsigned)VT.getSimpleVT().SimpleTy < MVT::LAST_VECTOR_VALUETYPE && ? Thanks, Micah -------------- next part -------------- An HTML attachment was...

...with the tablegen bits Hi Bruno, > Some comments: > > + // Try to synthesize horizontal adds from adds of shuffles. > + if (((Subtarget->hasSSE3()&& (VT == MVT::v4f32 || VT == MVT::v2f64)) || > + (Subtarget->hasAVX()&& (VT == MVT::v8f32 || VT == MVT::v4f64)))&& > + isHorizontalBinOp(LHS, RHS, true)) > > 1) You probably want to do something like: > > "bool HasHorizontalArith = Subtarget->hasSSE3() || > Subtarget->hasAVX()" and check it for the first condition, because > when AVX is on, the SSE levels a...