Ah, sorry for the duplication of effort. And thanks for the heads-up about
upcoming work! I don't think I have any plans for any of those others at the moment.
In the case of vld1_dup, however, I'm going to argue that my approach
(https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01718.html) is better, in that a
builtin is opaque (blocks optimization) for the midend, whereas gcc vector
extensions (as in vdup_n_...) allows the midend to perform constant-folding,
etc. Does that make sense?
--Alan
Yangfei (Felix) wrote:
These three are logically independent, but all on a common theme, and I've
tested them all together by
bootstrapped + check-gcc on aarch64-none-elf cross-tested check-gcc on
aarch64_be-none-elf
Ok for trunk?
Hi Alan,
It seems that we are duplicating the work for the vld1_dup part. (Refer to my message: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01462.html)
I have a plan to improve these intrinsics/builtins: vrsubhnX, vrsqrtX, vqrdmulX, vqmovX, vqdmulhqX, vqdmulhX, vpminX, vpmaxX, vpaddX, vpadaX
vmvnX, vmulxX, vmovnX, vmlsX,
vhsubX, vcvtX, vcopyX, vaddlvX, vabX, vfmX, vrecpeX, vcntX, vclsX
And work for these intrinsics is in progress: vfmX, vrecpeX, vhsubX,
vcntX, vclsX
Please let me know if you guys want to work on any of them. Thanks.
