search for: v16f32

Hi I find types such as v16i32, v16f32 missing in my llvm version 2.7 So does the following page not list them http://llvm.org/docs/doxygen/html/classllvm_1_1MVT.html is that intentional for any reason or can I just add them ? thanks shrey

On Wed, Jul 14, 2010 at 6:48 PM, shreyas krishnan <shreyas76 at gmail.com> wrote: > Hi >   I find  types such as v16i32, v16f32  missing in my llvm version 2.7 > > So does the following page not list them > http://llvm.org/docs/doxygen/html/classllvm_1_1MVT.html > > is that intentional for any reason or can I just add them  ? As far as I know, they're not there simply because there isn't any use for...

...<16 x float> vectors instead of <4 x float>: define void @vmaxf32(<16 x float> *%C, <16 x float>* %A, <16 x float>* %B) nounwind { %tmp1 = load <16 x float>* %A %tmp2 = load <16 x float>* %B %tmp3 = call <16 x float> @llvm.arm.neon.vmaxs.v16f32(<16 x float> %tmp1, <16 x float> %tmp2) store <16 x float> %tmp3, <16 x float>* %C ret void } declare <16 x float> @llvm.arm.neon.vmaxs.v16f32(<16 x float>, <16 x float>) nounwind readnone llc fails with following message: SplitVectorResult #...

...;); What does the assertion mean ? thanks for all help!! shrey On Wed, Jul 14, 2010 at 6:56 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Jul 14, 2010 at 6:48 PM, shreyas krishnan <shreyas76 at gmail.com> wrote: >> Hi >>   I find  types such as v16i32, v16f32  missing in my llvm version 2.7 >> >> So does the following page not list them >> http://llvm.org/docs/doxygen/html/classllvm_1_1MVT.html >> >> is that intentional for any reason or can I just add them  ? > > As far as I know, they're not there simply because...

...ors instead of <4 x float>: > > define void @vmaxf32(<16 x float> *%C, <16 x float>* %A, <16 x float>* %B) nounwind { > %tmp1 = load <16 x float>* %A > %tmp2 = load <16 x float>* %B > %tmp3 = call <16 x float> @llvm.arm.neon.vmaxs.v16f32(<16 x float> %tmp1, <16 x float> %tmp2) > store <16 x float> %tmp3, <16 x float>* %C > ret void > } > > declare <16 x float> @llvm.arm.neon.vmaxs.v16f32(<16 x float>, <16 x float>) nounwind readnone > > llc fails with following...

On Fri, Jul 16, 2010 at 5:14 PM, shreyas krishnan <shreyas76 at gmail.com> wrote: > I tried adding them in my backend however I run into the assertion > >  assert((unsigned)VT.SimpleTy < sizeof(LoadExtActions[0])*4 && >           ExtType < array_lengthof(LoadExtActions) && >           "Table isn't big enough!"); > > What does the

Thanks Eli ...I actually did that ..bumped it up by 2 that I had added. Any thing else that I might have done wrong ? I can see a different assert where it clearly depends on LAST_VALUETYPE assert((unsigned)VT.SimpleTy < MVT::LAST_VALUETYPE thanks shrey On Fri, Jul 16, 2010 at 5:20 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Fri, Jul 16, 2010 at 5:14 PM, shreyas

...ors instead of <4 x float>: > > define void @vmaxf32(<16 x float> *%C, <16 x float>* %A, <16 x float>* %B) nounwind { > %tmp1 = load <16 x float>* %A > %tmp2 = load <16 x float>* %B > %tmp3 = call <16 x float> @llvm.arm.neon.vmaxs.v16f32(<16 x float> %tmp1, <16 x float> %tmp2) > store <16 x float> %tmp3, <16 x float>* %C > ret void > } > > declare <16 x float> @llvm.arm.neon.vmaxs.v16f32(<16 x float>, <16 x float>) nounwind readnone > > llc fails with following...

...s) will provide the > result equivalent to serial scalar stores from least to most > significant vector elements. > > The new intrinsics are common for all targets, like recently > introduced masked load and store. > > Examples: > > <16 x float> @llvm.sindex.load.v16f32.v16i32 (i8 *%ptr, <16 x i32> %index, > i32 %scale) > <16 x float> @llvm.masked.sindex.load.v16f32.v16i32 (i8 *%ptr, <16 x i32> > %index, <16 x float> %passthru, <16 x i1> %mask) > void @llvm.sindex.store.v16f32.v16i64(i8* %ptr, <16 x float> %valu...

...;4 x float>: >> >> define void @vmaxf32(<16 x float> *%C, <16 x float>* %A, <16 x float>* %B) nounwind { >> %tmp1 = load <16 x float>* %A >> %tmp2 = load <16 x float>* %B >> %tmp3 = call <16 x float> @llvm.arm.neon.vmaxs.v16f32(<16 x float> %tmp1, <16 x float> %tmp2) >> store <16 x float> %tmp3, <16 x float>* %C >> ret void >> } >> >> declare <16 x float> @llvm.arm.neon.vmaxs.v16f32(<16 x float>, <16 x float>) nounwind readnone >> >&g...

...y (i.e., two indices with same or close values) will provide the result equivalent to serial scalar stores from least to most significant vector elements. The new intrinsics are common for all targets, like recently introduced masked load and store. Examples: <16 x float> @llvm.sindex.load.v16f32.v16i32 (i8 *%ptr, <16 x i32> %index, i32 %scale) <16 x float> @llvm.masked.sindex.load.v16f32.v16i32 (i8 *%ptr, <16 x i32> %index, <16 x float> %passthru, <16 x i1> %mask) void @llvm.sindex.store.v16f32.v16i64(i8* %ptr, <16 x float> %value, <16 x 164&gt...

On 21 September 2012 09:28, Sebastien DELDON-GNB <sebastien.deldon at st.com> wrote: > declare <16 x float> @llvm.arm.neon.vmaxs.v16f32(<16 x float>, <16 x float>) nounwind readnone > > llc fails with following message: > > SplitVectorResult #0: 0x2258350: v16f32 = llvm.arm.neon.vmaxs 0x2258250, 0x2258050, 0x2258150 [ORD=3] [ID=0] > > LLVM ERROR: Do not know how to split the result of this operator! &g...

...ed.expandload.* llvm.masked.compressstore.* The syntax of these two intrinsics is similar to the syntax of llvm.masked.load.* and masked.store.*, respectively, but the semantics are different, matching the above patterns. %res = call <16 x float> @llvm.masked.expandload.v16f32.p0f32 (float* %ptr, <16 x i1>%mask, <16 x float> %passthru) void @llvm.masked.compressstore.v16f32.p0f32 (<16 x float> <value>, float* <ptr>, <16 x i1> <mask>) The arguments - %mask, %value and %passthru all have the same vector length....

...>>>>> >>>>>>>>> >>>>>>>>> On Sun, Aug 6, 2017 at 1:59 AM, hameeza ahmed < >>>>>>>>> hahmed2305 at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> for v16f32 it is defined as; >>>>>>>>>> : Pat<(v16f32 (X86VBroadcast (v16f32 VR512:$src))), >>>>>>>>>> (VBROADCASTSSZr (EXTRACT_SUBREG (v16f32 VR512:$src), >>>>>>>>>> sub_xmm))>; >>>>>>&...

...compressstore.* |> |> The syntax of these two intrinsics is similar to the syntax of |> llvm.masked.load.* and masked.store.*, respectively, but the |semantics |> are different, matching the above patterns. |> |> %res = call <16 x float> @llvm.masked.expandload.v16f32.p0f32 |(float* |> %ptr, <16 x i1>%mask, <16 x float> %passthru) void |> @llvm.masked.compressstore.v16f32.p0f32 (<16 x float> <value>, |> float* <ptr>, <16 x i1> <mask>) |> |> The arguments - %mask, %value and %passthru all have t...

...;>>>>>> >>>>>>>>>>> On Sun, Aug 6, 2017 at 1:59 AM, hameeza ahmed < >>>>>>>>>>> hahmed2305 at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> for v16f32 it is defined as; >>>>>>>>>>>> : Pat<(v16f32 (X86VBroadcast (v16f32 VR512:$src))), >>>>>>>>>>>> (VBROADCASTSSZr (EXTRACT_SUBREG (v16f32 VR512:$src), >>>>>>>>>>>> sub_xmm))>; &...

...t;>>>>> On Sun, Aug 6, 2017 at 1:59 AM, hameeza ahmed < >>>>>>>>>>>>>>> hahmed2305 at gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> for v16f32 it is defined as; >>>>>>>>>>>>>>>> : Pat<(v16f32 (X86VBroadcast (v16f32 VR512:$src))), >>>>>>>>>>>>>>>> (VBROADCASTSSZr (EXTRACT_SUBREG (v16f32 >>>>>>>>>>>&g...

...ax of these two intrinsics is similar to the syntax of |> |> llvm.masked.load.* and masked.store.*, respectively, but the |> |semantics |> |> are different, matching the above patterns. |> |> |> |> %res = call <16 x float> @llvm.masked.expandload.v16f32.p0f32 |> |(float* |> |> %ptr, <16 x i1>%mask, <16 x float> %passthru) void |> |> @llvm.masked.compressstore.v16f32.p0f32 (<16 x float> |<value>, |> |> float* <ptr>, <16 x i1> <mask>) |> |> |> |> The...

...true. This results in the following issues: 1. On X86(-64) targets, ISD::FMA nodes are formed when lowering fmuladd intrinsics even if the subtarget does not support FMA instructions, leading to laughably bad code generation in some situations (for example, compiling a call to "@llvm.fmuladd.v16f32(<16 x float> %a, <16 x float> %b, <16 x float> %c)" without "-mattr=+fma" or "-mattr=+fma4" results in 16 calls for the fmaf libm function instead of AVX muls and adds. 2. On AArch64 targets, ISD::FMA nodes are formed for operations on fp128, resulting in...

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