[dpdk-dev] [EXT] [PATCH 1/3] acl: fix arm argument types

[Jerin Jacob Kollanukkaran]

> -----Original Message-----
> From: Jerin Jacob Kollanukkaran
> Sent: Wednesday, April 10, 2019 8:10 PM
> To: dev at dpdk.org; aconole at redhat.com
> Cc: gavin.hu at arm.com; konstantin.ananyev at intel.com
> Subject: Re: [EXT] [PATCH 1/3] acl: fix arm argument types
> 
> On Mon, 2019-04-08 at 14:24 -0400, Aaron Conole wrote:
> > -------------------------------------------------------------------
> > ---
> > Compiler complains of argument type mismatch, like:
> 
> Can you share more details on how to reproduce this issue?
> 
> We already have
> CFLAGS_acl_run_neon.o += -flax-vector-conversions in the Makefile.
> 
> If you are taking out -flax-vector-conversions the correct way to fix will be
> use vreinterpret*.
> 
> For me the code looks clean, If unnecessary casting is avoided.


Considering the following patch is part of dpdk.org now. I think, We may not need this
patch in benefit to avoid a lot of typecasting.

https://git.dpdk.org/dpdk/commit/?id=e53ce4e4137974f46743e74bd9ab912e0166c8b1




> 
> 
> >
> >    ../lib/librte_acl/acl_run_neon.h: In function ‘transition4’:
> >    ../lib/librte_acl/acl_run_neon.h:115:2: note: use -flax-vector-
> > conversions
> >       to permit conversions between vectors with differing element
> > types
> >       or numbers of subparts
> >      node_type = vbicq_s32(tr_hi_lo.val[0], index_msk);
> >      ^
> >    ../lib/librte_acl/acl_run_neon.h:115:41: error: incompatible type
> > for
> >       argument 2 of ‘vbicq_s32’
> >
> > Signed-off-by: Aaron Conole <aconole at redhat.com>
> > ---
> >  lib/librte_acl/acl_run_neon.h | 46 ++++++++++++++++++++-------------
> > --
> >  1 file changed, 27 insertions(+), 19 deletions(-)
> >
> >
> >
> >  /*
> > @@ -179,6 +183,9 @@ search_neon_8(const struct rte_acl_ctx *ctx, const
> > uint8_t **data,
> >  	acl_match_check_x4(0, ctx, parms, &flows, &index_array[0]);
> >  	acl_match_check_x4(4, ctx, parms, &flows, &index_array[4]);
> >
> > +	memset(&input0, 0, sizeof(input0));
> > +	memset(&input1, 0, sizeof(input1));
> 
> Why this memset only required for arm64? If it real issue, Shouldn't it
> required for x86 and ppc ?
>