similar to: [LLVMdev] Vectors in structures

On Sep 21, 2010, at 9:33 AM, Renato Golin wrote: > 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? Because that is what ARM has specified? They define the vector types that are used with their NEON intrinsics as

Bob Wilson writes: > On Sep 21, 2010, at 9:33 AM, Renato Golin wrote: > > 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? > > Because that is what ARM has specified? They define the vector types > that are used with their NEON

On Tue, Sep 21, 2010 at 11:07 PM, Alasdair Grant <Alasdair.Grant at arm.com> wrote: > Bob Wilson writes: >> On Sep 21, 2010, at 9:33 AM, Renato Golin wrote: >> > 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?

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

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 27 September 2010 18:19, Bob Wilson <bob.wilson at apple.com> wrote: > I'm not sure what you mean by this.  The llvm intrinsics and built-in vector operations use plain vectors regardless of the front-end.  The structures are only relevant for things like argument passing and copying -- you can't do anything else with them.  Can you post an example of the 5X IR code size that

On Sep 21, 2010, at 10:14 AM, Renato Golin wrote: > 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

> They are defined as structures. The table in A.2 defines the exact > structure names. There is a requirement to mangle them as those > structures in A.2.1. The mangling requirement doesn't require you to meet it in any particular way as long as you end up with the right strings. I.e. the mangling requirement places no requirements at all on the implementation, outside of mangled

On Sep 21, 2010, at 4:33 PM, Sandeep Patel wrote: > On Tue, Sep 21, 2010 at 11:07 PM, Alasdair Grant <Alasdair.Grant at arm.com> wrote: >> Bob Wilson writes: >>> On Sep 21, 2010, at 9:33 AM, Renato Golin wrote: >>>> I was checking NEON instructions this week and the vector types seem >>>> to be inside structures. If vector types are considered

On 28 September 2010 19:54, Bob Wilson <bob.wilson at apple.com> wrote: > Really?  ARM's specifications of these types show them as structs, and as my example demonstrates, GCC's "implementation choice" allows code that is incompatible with ARM's compiler.  I guess you are saying that is OK. OK in the sense that it works, yes. OK in the sense that I welcome it, then

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

I have a code generation question for ARM with VFP and NEON. I am generating code for the following function as a test: void FloatingPointTest(float f1, float f2, float f3) { float f4 = f1 * f2; if (f4 > f3) printf("%f\n",f2); else printf("%f\n",f3); } I have tried compiling with: 1. -mfloat-abi=softfp and -mfpu=neon 2.

Hi, Optimizes celt_pitch_xcorr for floating point. Changes from RFCv1: - Rebased on top of commit aad281878: Fix celt_pitch_xcorr_c signature. which got rid of ugly code around CELT_PITCH_XCORR_IMPL passing of "arch" parameter. - Unified with --enable-intrinsics used by x86 - Modified algorithm to be more in-line with algorithm in celt_pitch_xcorr_arm.s Viswanath Puttagunta

Hi all, LLVM CodeGen and Tools team at Apple is looking for exceptional compiler engineers. This is a great opportunity to work with many of the leaders in the LLVM community. If you are interested in this position, please send your resume / CV and relevant information to evan.cheng at apple.com Thanks, Evan Job description The Apple compiler team is seeking an engineer who is strongly

On 27 September 2010 23:45, Bob Wilson <bob.wilson at apple.com> wrote: > An implementation, such as in GCC, that does not use structures is compatible with ARM's specification in only one direction.  GCC will accept any code written for RVCT, but not the other way around.  And, as Al pointed out, there are also compatibility issues with how you can initialize vectors.  (In fact, if

Hello Tim, thanks for response ---------------------------------------- > Date: Mon, 20 Apr 2015 11:45:03 -0700 > Subject: Re: [LLVMdev] question about alignment of structures on the stack (arm 32) > From: t.p.northover at gmail.com > To: alexey.perevalov at hotmail.com > CC: llvmdev at cs.uiuc.edu > > On 20 April 2015 at 11:09, Alexey Perevalov > <alexey.perevalov at

On Sep 27, 2010, at 2:58 AM, Renato Golin wrote: > On 22 September 2010 03:43, Bob Wilson <bob.wilson at apple.com> wrote: >> But regardless they are still structures, right? What does it mean for them to map onto other types? Is the parser supposed to treat them as if they _were_ those other types? If so, I think you need to define a type system for those fundamental vector

On 22 September 2010 03:43, Bob Wilson <bob.wilson at apple.com> wrote: > But regardless they are still structures, right?  What does it mean for them to map onto other types?  Is the parser supposed to treat them as if they _were_ those other types?  If so, I think you need to define a type system for those fundamental vector types.  I had read those statements to say something about the

On Sep 28, 2010, at 2:07 AM, Renato Golin wrote: > On 27 September 2010 23:45, Bob Wilson <bob.wilson at apple.com> wrote: >> An implementation, such as in GCC, that does not use structures is compatible with ARM's specification in only one direction. GCC will accept any code written for RVCT, but not the other way around. And, as Al pointed out, there are also compatibility

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,