On Wed, 18 Aug 2021 at 20:10, Martin Sebor wrote:
>
> On 8/18/21 12:52 AM, Prathamesh Kulkarni wrote:
> > On Fri, 13 Aug 2021 at 22:44, Martin Sebor wrote:
> >>
> >> On 8/12/21 2:32 AM, Prathamesh Kulkarni wrote:
> >>> On Sat, 7 Aug 2021 at 02:09, Martin Sebor wrote:
>
> On 8/6/21 4:51 AM, Richard Earnshaw wrote:
> >
> >
> > On 06/08/2021 01:06, Martin Sebor via Gcc wrote:
> >> On 8/4/21 3:46 AM, Richard Earnshaw wrote:
> >>>
> >>>
> >>> On 03/08/2021 18:44, Martin Sebor wrote:
> On 8/3/21 4:11 AM, Prathamesh Kulkarni via Gcc wrote:
> > On Tue, 27 Jul 2021 at 13:49, Richard Biener
> > wrote:
> >>
> >> On Mon, Jul 26, 2021 at 11:06 AM Prathamesh Kulkarni via Gcc
> >> wrote:
> >>>
> >>> On Fri, 23 Jul 2021 at 23:29, Andrew Pinski
> >>> wrote:
>
> On Fri, Jul 23, 2021 at 3:55 AM Prathamesh Kulkarni via Gcc
> wrote:
> >
> > Hi,
> > Continuing from this thread,
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575920.html
> > The proposal is to provide a mechanism to mark a parameter in a
> > function as a literal constant.
> >
> > Motivation:
> > Consider the following intrinsic vshl_n_s32 from
> > arrm/arm_neon.h:
> >
> > __extension__ extern __inline int32x2_t
> > __attribute__ ((__always_inline__, __gnu_inline__,
> > __artificial__))
> > vshl_n_s32 (int32x2_t __a, const int __b)
> > {
> > return (int32x2_t)__builtin_neon_vshl_nv2si (__a, __b);
> > }
> >
> > and it's caller:
> >
> > int32x2_t f (int32x2_t x)
> > {
> > return vshl_n_s32 (x, 1);
> > }
>
> Can't you do similar to what is done already in the aarch64
> back-end:
> #define __AARCH64_NUM_LANES(__v) (sizeof (__v) / sizeof (__v[0]))
> #define __AARCH64_LANE_CHECK(__vec, __idx) \
> __builtin_aarch64_im_lane_boundsi (sizeof(__vec),
> sizeof(__vec[0]), __idx)
>
> ?
> Yes this is about lanes but you could even add one for min/max
> which
> is generic and such; add an argument to say the intrinsics name
> even.
> You could do this as a non-target builtin if you want and reuse
> it
> also for the aarch64 backend.
> >>> Hi Andrew,
> >>> Thanks for the suggestions. IIUC, we could use this approach to
> >>> check
> >>> if the argument
> >>> falls within a certain range (min / max), but I am not sure how it
> >>> will help to determine
> >>> if the arg is a constant immediate ? AFAIK, vshl_n intrinsics
> >>> require
> >>> that the 2nd arg is immediate ?
> >>>
> >>> Even the current RTL builtin checking is not consistent across
> >>> optimization levels:
> >>> For eg:
> >>> int32x2_t f(int32_t *restrict a)
> >>> {
> >>> int32x2_t v = vld1_s32 (a);
> >>> int b = 2;
> >>> return vshl_n_s32 (v, b);
> >>> }
> >>>
> >>> With pristine trunk, compiling with -O2 results in no errors
> >>> because
> >>> constant propagation replaces 'b' with 2, and during expansion,
> >>> expand_builtin_args is happy. But at -O0, it results in the error
> >>> -
> >>> "argument 2 must be a constant immediate".
> >>>
> >>> So I guess we need some mechanism to mark a parameter as a
> >>> constant ?
> >>
> >> I guess you want to mark it in a way that the frontend should force
> >> constant evaluation and error if that's not possible? C++ doesn't
> >> allow to declare a parameter as 'constexpr' but something like
> >>
> >> void foo (consteval int i);
> >>
> >> since I guess you do want to allow passing constexpr arguments
> >> in C++ or in C extended forms of constants like
> >>
> >> static const int a[4];
> >>
> >> foo (a[1]);
> >>
> >> ? But yes, this looks useful to me.
> > Hi Richard,
> > Thanks for the suggestions and sorry for late response.
> > I have attached a prototype patch that implements consteval
> > attribute.
> > As implemented, the attribute takes at least one argument(s), which
> > refer to parameter position,
> > and the corresponding parameter must be const qualified, failing
> > which, the attribute is ignored.
>
> I'm curious why the ar
