similar to: [LLVMdev] NEON intrinsics

Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] NEON intrinsics"

2010 Sep 21
2
[LLVMdev] NEON intrinsics
On 21 September 2010 21:16, Bob Wilson <bob.wilson at apple.com> wrote: > It's referring to the arm.neon.vabds intrinsic, which is different than the old vabal intrinsic. Ok, sorry, those were the ones I was referring to: @llvm.arm.neon.* intrinsics. Is it polluting too much to add the few last (llvm.arm.neon.vadd, llvm.arm.neon.vsub)? It makes it a bit easier to generate neon
2010 Sep 21
2
[LLVMdev] NEON intrinsics
On 21 September 2010 20:30, Bob Wilson <bob.wilson at apple.com> wrote: > The intrinsics that have been removed are no longer defined, so I don't see how ARMInstrNEON.td could be using them.  I really don't know what you're referring to, though. Hi Bob, Example: lib/VMCore/AutoUpgrade.cpp:91: Name.compare(14, 5, "vabal", 5) == 0) &&
2010 Sep 21
0
[LLVMdev] NEON intrinsics
On Sep 21, 2010, at 10:09 AM, Renato Golin wrote: > Third question: (sorry) > > NEON intrinsics. Some of them are direct operations (types are the > same, return type is the same), some of them are intrinsics. > > So far so good, but why not make them all intrinsics? I mean, it's ok > to have ADD <i8 x 8> transform into a NEON operation, but why not have >
2010 Sep 21
2
[LLVMdev] NEON intrinsics
On 21 September 2010 19:19, Bob Wilson <bob.wilson at apple.com> wrote: > There's no reason to have clang builtins for operations that can be represented directly.  It just bloats the compiler.  Please don't do that. Ok, so why are some in there already? There is a validation pass (in a pretty generic place, not ARM related: VMCore/AutoUpgrade.cpp) that filters them out as plain
2010 Sep 21
0
[LLVMdev] NEON intrinsics
On Sep 21, 2010, at 1:03 PM, Renato Golin wrote: > On 21 September 2010 20:30, Bob Wilson <bob.wilson at apple.com> wrote: >> The intrinsics that have been removed are no longer defined, so I don't see how ARMInstrNEON.td could be using them. I really don't know what you're referring to, though. > > Hi Bob, > > Example: > >
2010 Sep 21
2
[LLVMdev] NEON intrinsics
On 21 September 2010 20:02, Bob Wilson <bob.wilson at apple.com> wrote: > That code is to support reading old bitcode files containing intrinsics that no longer exist or that have different arguments/usage than in previous versions of llvm.  It's not a validation pass, and it's not relevant to any new IR.  It's only for backward compatibility. Oh, I see. So we should also
2010 Sep 21
0
[LLVMdev] NEON intrinsics
On Sep 21, 2010, at 1:31 PM, Renato Golin wrote: > On 21 September 2010 21:16, Bob Wilson <bob.wilson at apple.com> wrote: >> It's referring to the arm.neon.vabds intrinsic, which is different than the old vabal intrinsic. > > Ok, sorry, those were the ones I was referring to: @llvm.arm.neon.* intrinsics. > > Is it polluting too much to add the few last
2012 Sep 21
2
[LLVMdev] RE : Question about LLVM NEON intrinsics
Hello Renato, You're pointing me at ARM intrinsics related to loads, problem that I've reported in original e-mail, is not support for vector loads, but support for 'vmaxs'. For instance, there is no vector loads of 16 floats in ARM ISA but it is legal to write in LLVM: ; ModuleID = 'vadd.ll' target datalayout =
2012 Sep 21
0
[LLVMdev] Question about LLVM NEON intrinsics
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
2012 Sep 21
5
[LLVMdev] Question about LLVM NEON intrinsics
Hi all, I would like to know if LLVM Neon intrinsics are designed to support only 'Legal' types for NEON units. Using llc -march=arm -mcpu=cortex-a9 vmax4.ll -o vmax4.s on following ll code: ; ModuleID = 'vmax.ll' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-n32" target triple =
2010 Sep 21
0
[LLVMdev] NEON intrinsics
On Sep 21, 2010, at 12:28 PM, Renato Golin wrote: > On 21 September 2010 20:02, Bob Wilson <bob.wilson at apple.com> wrote: >> That code is to support reading old bitcode files containing intrinsics that no longer exist or that have different arguments/usage than in previous versions of llvm. It's not a validation pass, and it's not relevant to any new IR. It's only
2010 Sep 21
3
[LLVMdev] Vectors in structures
Second question: I was checking NEON instructions this week and the vector types seem to be inside structures. If vector types are considered proper types in LLVM, why pack them inside structures? That results in a lot of boilerplate code for converting and copying the values (about 20 lines of IR) just to call a NEON instruction that, in the end, will be converted into three instructions: VLDR
2010 Sep 21
0
[LLVMdev] NEON intrinsics
On Sep 21, 2010, at 11:59 AM, Renato Golin wrote: > On 21 September 2010 19:19, Bob Wilson <bob.wilson at apple.com> wrote: >> There's no reason to have clang builtins for operations that can be represented directly. It just bloats the compiler. Please don't do that. > > Ok, so why are some in there already? There is a validation pass (in a > pretty generic
2010 Sep 28
2
[LLVMdev] Vectors in structures
On 28 September 2010 18:20, Bob Wilson <bob.wilson at apple.com> wrote: > Yes, there are multiple issues but they all involve source compatibility. Hi Bob, than this is a completely different matter altogether. > I do not have access to ARM's compiler(s) but I'm assuming that the first example will not compile because vadd_u32 expects arguments of type uint32x2_t.  Using
2010 Sep 27
0
[LLVMdev] Vectors in structures
Support for NEON intrinsics in clang is not complete. Poly types in general are known to be an issue, and the vceq_p8 in your example definitely needs an intrinisic. It should work with llvm-gcc. Can you clarify ARM's position on those structure types? It sounds like you are advocating that we get rid of them. The only reason we've been using them in llvm-gcc and clang is for
2010 Sep 27
2
[LLVMdev] Vectors in structures
On 27 September 2010 23:03, Bob Wilson <bob.wilson at apple.com> wrote: > Can you clarify ARM's position on those structure types?  It sounds like you are advocating that we get rid of them.  The only reason we've been using them in llvm-gcc and clang is for compatibility for ARM's specifications and with ARM's RVCT compiler.  If ARM does not care about those things,
2014 Dec 09
1
[RFC PATCH v2] armv7: celt_pitch_xcorr: Introduce ARM neon intrinsics
Viswanath Puttagunta wrote: > + SUMM = vdupq_n_f32(0); It kills me that there's no intrinsic for VMOV.F32 d0, #0 (or at least I couldn't find one), so this takes two instructions instead of one. > + /* Consume 4 elements in x vector and 8 elements in y > + * vector. However, the 8'th element in y never really gets > + * touched in this loop. So, if len == 4,
2010 Sep 21
2
[LLVMdev] Vectors in structures
On 21 September 2010 18:03, Bob Wilson <bob.wilson at apple.com> wrote: > Because that is what ARM has specified?  They define the vector types that are used with their NEON intrinsics as "containerized vectors".  Perhaps someone on the list from ARM can explain why they did it that way. That's ok, but why do you need to do that in the IR? I mean, in the end, the
2013 Feb 08
0
[LLVMdev] Is there any llvm neon intrinsic that maps to vmla.f32 instruction ?
On 8 February 2013 10:40, Sebastien DELDON-GNB <sebastien.deldon at st.com>wrote: > Hi all,**** > > ** ** > > Everything is in the tile, I would like to enforce generation of vmla.f32 > instruction for scalar operations on cortex-a9, so is there a LLMV neon > intrinsic available for that ?**** > > Hi Sebastien, LLVM doesn't use intrinsics when there is a
2013 Dec 19
4
[LLVMdev] LLVM ARM VMLA instruction
Hi Tim, > > cortex-a15 vfpv4 : vmla instruction emitted (which is a NEON instruction) > > I get a VFP vmla here rather than a NEON one (clang -target > armv7-linux-gnueabihf -mcpu=cortex-a15): "vmla.f32 s0, s1, s2". Are > you seeing something different? > As per Renato comment above, vmla instruction is NEON instruction while vmfa is VFP instruction. Correct