This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ARM NEON Intrinsics guide?


> As has been mentioned on this thread already,
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0073a/IHI0073A_arm_neon_intrinsics_ref.pdf
> is a list of the intrinsics and how they map down to NEON instructions,
> thought it's
> more of a reference rather than a user guide.
>
> If you can isolate a standalone example where GCC NEON intrinsics perform
> poorly it can you
> please file a bug report with the testcase.

I hope to get something together shortly.

Here's one of the pain points:

   int64x2_t c = vcombine_s64(vget_high_s64(a),vget_low_s64(b));

I'm testing alternatives at the moment... It looks like lane
extraction and insertion produces better code under GCC. It seems to
limit GCC's desire to spill out into R registers.

> As an aside, I notice your command-line options are sub-optimal.
> If you're targeting a Cortex-A7  you want to use -mfpu=neon-vfpv4 rather
> than just -mfpu=neon.
> This will give you access to the vfma instructions.
> Whereas if you're targeting ARMv8-A on a Cortex-A53 you'll want to use
> -mfpu=neon-fp-armv8
> to enable the ARMv8 floating-point an NEON instructions.

Thanks, this is the sort of thing I was looking for: higher level prescriptions.

I'm also looking for something on creating new vectors on the fly from
scattered data. vcombine_s64 is a pain point under this data set, and
the suggestions here don't apply:
https://community.arm.com/groups/processors/blog/2012/03/13/coding-for-neon--part-5-rearranging-vectors.

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]