Yeah, I agree that your approach is better. I missed this point. Thanks.
> > 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. > > >
