[dpdk-dev,v2] eal/armv8: fix poly64/128 compile issue in old GCC(<4.9.0)

  Use built-in data types for unsupported poly64/128 types
for GCC version lower than 4.9.0

Fixes: 3c4b4024c225 ("arch/arm: add vcopyq_laneq_u32 for old gcc")

Signed-off-by: Herbert Guan <herbert.guan@arm.com>
---
 lib/librte_eal/common/include/arch/arm/rte_vect.h | 7 +++++++
 1 file changed, 7 insertions(+)
  

13/07/2017 05:16, Herbert Guan:
> --- a/lib/librte_eal/common/include/arch/arm/rte_vect.h
> +++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> +#if (GCC_VERSION < 40900)
> +typedef uint64_t poly64_t;
> +typedef uint64x2_t poly64x2_t;
> +typedef uint8_t poly128_t __attribute__((vector_size(16), aligned(16)));
> +#endif

I think a better fix would be to switch to DPDK types
like rte_v128u8_t.
  

Thomas,

Thanks a lot for your review and comment.  But I have some concern in this approach.  "poly128_t" is for ARM64 platform only and in fact it's more likely that rte_v128u8_t (generic DPDK data type) could be defined from poly128_t (ARM data type) which seems more reasonable.

Best regards,
Herbert

-----Original Message-----
From: Thomas Monjalon [mailto:thomas@monjalon.net]
Sent: Tuesday, July 18, 2017 22:44
To: Herbert Guan <Herbert.Guan@arm.com>
Cc: dev@dpdk.org; jianbo.liu@linaro.org; jerin.jacob@caviumnetworks.com; nelio.laranjeiro@6wind.com
Subject: Re: [dpdk-dev] [PATCH v2] eal/armv8: fix poly64/128 compile issue in old GCC(<4.9.0)

13/07/2017 05:16, Herbert Guan:
> --- a/lib/librte_eal/common/include/arch/arm/rte_vect.h
> +++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> +#if (GCC_VERSION < 40900)
> +typedef uint64_t poly64_t;
> +typedef uint64x2_t poly64x2_t;
> +typedef uint8_t poly128_t __attribute__((vector_size(16), aligned(16)));
> +#endif

I think a better fix would be to switch to DPDK types
like rte_v128u8_t.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
  

19/07/2017 11:21, Herbert Guan:
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > 13/07/2017 05:16, Herbert Guan:
> > > --- a/lib/librte_eal/common/include/arch/arm/rte_vect.h
> > > +++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> > > +#if (GCC_VERSION < 40900)
> > > +typedef uint64_t poly64_t;
> > > +typedef uint64x2_t poly64x2_t;
> > > +typedef uint8_t poly128_t __attribute__((vector_size(16),
> > > aligned(16)));
> > > +#endif
> > 
> > I think a better fix would be to switch to DPDK types
> > like rte_v128u8_t.
> 
> Thanks a lot for your review and comment.
> But I have some concern in this approach.  "poly128_t" is for
> ARM64 platform only and in fact it's more likely that rte_v128u8_t
> (generic DPDK data type) could be defined from poly128_t
> (ARM data type) which seems more reasonable.

How poly128_t is different from rte_v128u8_t?
You are defining poly128_t as (vector_size(16),aligned(16))
and rte_v128u8_t is exactly that.
Is it interpreted differently with newer compilers?
In that case, you could at least fallback on rte_v128u8_t.
  

"poly128_t" is an arm data type provided in GCC later than 4.9.0.  But it's not defined in earlier GCC.  To make the code get compiled with early version GCC, this patch is provided.

In this way, "rte_v128u8_t" do is having the same definition as poly128_t in this patch.  But in GCC 4.9.0 and later (e.g. 7.0.0), poly128_t is not interpreted the same way.  They are using some new built-in data types:

typedef __builtin_neon_poly64 poly64_t;
typedef __builtin_neon_poly128 poly128_t;

For example, if we need to replace the vector types' interpretation with ARM's data types, then we should not include "generic/rte_vect.h" in "common/include/arch/arm/rte_vect.h" and then interpret these data types in arm/rte_vect.h.  So "typedef poly128_t rte_v128u8_t" is okay but "typedef rte_v128u8_t poly128_t" is not.  For this reason, I think " typedef uint8_t poly128_t __attribute__((vector_size(16), aligned(16)));" is better.

Could you comment if having different thoughts or concerns?


Thanks,
Herbert

-----Original Message-----
From: Thomas Monjalon [mailto:thomas@monjalon.net]
Sent: Wednesday, July 19, 2017 20:31
To: Herbert Guan <Herbert.Guan@arm.com>
Cc: dev@dpdk.org; jianbo.liu@linaro.org; jerin.jacob@caviumnetworks.com; nelio.laranjeiro@6wind.com
Subject: Re: [dpdk-dev] [PATCH v2] eal/armv8: fix poly64/128 compile issue in old GCC(<4.9.0)

19/07/2017 11:21, Herbert Guan:
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > 13/07/2017 05:16, Herbert Guan:
> > > --- a/lib/librte_eal/common/include/arch/arm/rte_vect.h
> > > +++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> > > +#if (GCC_VERSION < 40900)
> > > +typedef uint64_t poly64_t;
> > > +typedef uint64x2_t poly64x2_t;
> > > +typedef uint8_t poly128_t __attribute__((vector_size(16),
> > > aligned(16)));
> > > +#endif
> >
> > I think a better fix would be to switch to DPDK types like
> > rte_v128u8_t.
>
> Thanks a lot for your review and comment.
> But I have some concern in this approach.  "poly128_t" is for
> ARM64 platform only and in fact it's more likely that rte_v128u8_t
> (generic DPDK data type) could be defined from poly128_t (ARM data
> type) which seems more reasonable.

How poly128_t is different from rte_v128u8_t?
You are defining poly128_t as (vector_size(16),aligned(16)) and rte_v128u8_t is exactly that.
Is it interpreted differently with newer compilers?
In that case, you could at least fallback on rte_v128u8_t.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
  

13/07/2017 04:16, Herbert Guan:
> Use built-in data types for unsupported poly64/128 types
> for GCC version lower than 4.9.0
> 
> Fixes: 3c4b4024c225 ("arch/arm: add vcopyq_laneq_u32 for old gcc")
> 
> Signed-off-by: Herbert Guan <herbert.guan@arm.com>

Applied, thanks