similar to: [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

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) &&

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 >

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

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

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

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

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 =

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

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 =

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

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

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

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

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

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,

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,

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

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

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