From: Herbert Guan <Herbert.Guan@arm.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"jianbo.liu@linaro.org" <jianbo.liu@linaro.org>,
"jerin.jacob@caviumnetworks.com" <jerin.jacob@caviumnetworks.com>,
"nelio.laranjeiro@6wind.com" <nelio.laranjeiro@6wind.com>
Subject: Re: [dpdk-dev] [PATCH v2] eal/armv8: fix poly64/128 compile issue in old GCC(<4.9.0)
Date: Mon, 24 Jul 2017 10:25:29 +0000 [thread overview]
Message-ID: <HE1PR08MB280949317EED631DB948E80986BB0@HE1PR08MB2809.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <7214394.Gg28SKYvWX@xps>
"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.
next prev parent reply other threads:[~2017-07-24 10:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-12 10:50 [dpdk-dev] [PATCH] ARMv8: Use built-in data types for unsupported poly64/128 types for GCC version lower than 4.9.0 Herbert Guan
2017-07-12 15:36 ` Jianbo Liu
2017-07-12 17:45 ` Jerin Jacob
2017-07-13 3:13 ` Herbert Guan
2017-07-13 2:16 ` [dpdk-dev] [PATCH v2] eal/armv8: fix poly64/128 compile issue in old GCC(<4.9.0) Herbert Guan
2017-07-18 14:44 ` Thomas Monjalon
2017-07-19 8:21 ` Herbert Guan
2017-07-19 12:31 ` Thomas Monjalon
2017-07-24 10:25 ` Herbert Guan [this message]
2017-07-31 7:24 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=HE1PR08MB280949317EED631DB948E80986BB0@HE1PR08MB2809.eurprd08.prod.outlook.com \
--to=herbert.guan@arm.com \
--cc=dev@dpdk.org \
--cc=jerin.jacob@caviumnetworks.com \
--cc=jianbo.liu@linaro.org \
--cc=nelio.laranjeiro@6wind.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).