This is the mail archive of the gcc-patches@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: [PATCH 0/3][AArch64]More intrinsics/builtins improvements


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.
> >
> 


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