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

[Herbert Guan]

"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 at monjalon.net]
Sent: Wednesday, July 19, 2017 20:31
To: Herbert Guan <Herbert.Guan at arm.com>
Cc: dev at dpdk.org; jianbo.liu at linaro.org; jerin.jacob at caviumnetworks.com; nelio.laranjeiro at 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 at 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.