> -----Original Message----- > From: Richard Sandiford [mailto:richard.sandif...@arm.com] > Sent: Monday, July 6, 2020 5:31 PM > To: xiezhiheng <xiezhih...@huawei.com> > Cc: Richard Biener <richard.guent...@gmail.com>; gcc-patches@gcc.gnu.org > Subject: Re: [PATCH PR94442] [AArch64] Redundant ldp/stp instructions > emitted at -O3 > > No, this is unfortunately a known bug. See: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95964 > > (Although the PR is recent, it's been a known bug for longer.) > > As you say, the difficulty is that the correct attributes depend on what > the built-in function does. Most integer arithmetic is “const”, but things > get more complicated for floating-point arithmetic. > > The SVE intrinsics use a three stage process: > > - each function is classified into one of several groups > - each group has a set of flags that describe what functions in the > group can do > - these flags get converted into attributes based on the current > command-line options > > I guess we should have something similar for the arm_neon.h built-ins. > > If you're willing to help fix this, that'd be great. I think a first > step would be to agree a design. > > Thanks, > Richard
I'd like to have a try. I have checked the steps in SVE intrinsics. It defines a base class "function_base" and derives different classes to describe several intrinsics for each. And each class may have its own unique flags described in virtual function "call_properties". The specific attributes will be converted from these flags in "get_attributes" later. I find that there are more than 100 classes in total and if I only need to classify them into different groups by attributes, maybe we does not need so many classes? The difficult thing I think is how to classify neon intrinsics into different groups. I'm going to follow up the way in SVE intrinsics first now. Xie Zhiheng