Ok, thanks Charles - sorry for/if duplication of effort, that just spun out of
trying to get rid of the calls to aarch64_simd_lane_bounds, as per
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02510.html . Again as per that
message I'm leaving aarch64_ld{2,3,4}_lane<mode> to you ;).
Also there is the ARM backend! There's quite a lot to port across AArch64->ARM
but my first priority is to try to get float16_t intrinsics working on ARM, i.e.
probably doing as little as possible to get vget_lane_f16 etc. and then focus on
performance later. Wondering if you have any plans for ARM ?
--Alan
Charles Baylis wrote:
On 5 December 2014 at 11:45, Alan Lawrence <alan.lawre...@arm.com> wrote:
Following on from Charles Baylis' patch to improve the error message when
expanding arguments with qualifier_lane_index, this applies similar
treatment to __builtin_aarch64_im_lane_boundsi (using for e.g. vset_lane and
vext), and the more general case of immediates which should be constant but
aren't.
These patches depend upon the __aarch64_lane macro in
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg03134.html .
All patches cross-tested with check-gcc on aarch64-none-elf and
aarch64_be-none-elf.
Ok for trunk (following
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg03134.html) ?
All look good to me (but I can't approve), except that the changelogs
should be marked with PR target/63870
I was about to submit a patch series for vldN_lane and vstN_lane with
a version of patch #1, but yours is much better than mine. I'll drop
that part and send it on ASAP.
Cheers
Charles
