From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0088.outbound.protection.outlook.com [104.47.1.88]) by dpdk.org (Postfix) with ESMTP id 8A5E17D00 for ; Mon, 24 Jul 2017 12:25:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yl3SjURvaC6Gp9aQfu27xuww5/MInn3oW+KvUmeMyA8=; b=Wbgrb+8HlWg7ZBt39URaWFaxNbSR+5RexnygkCQ7zBGnN/wfidarrF0XaeH3rmuc9NSNkj8WUveNfYqbqjFlDej3+8P1PasNLlSdvrrJp6wLtJoDRGgn8HiAgUMp1UW7TCrqUJOvEoVqCkCCNY8IJGC0cM9DL9SYUyjpHgqA4BA= Received: from HE1PR08MB2809.eurprd08.prod.outlook.com (10.170.246.148) by HE1PR08MB2811.eurprd08.prod.outlook.com (10.170.246.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Mon, 24 Jul 2017 10:25:30 +0000 Received: from HE1PR08MB2809.eurprd08.prod.outlook.com ([fe80::1074:f9ad:c2c1:26f7]) by HE1PR08MB2809.eurprd08.prod.outlook.com ([fe80::1074:f9ad:c2c1:26f7%13]) with mapi id 15.01.1282.017; Mon, 24 Jul 2017 10:25:29 +0000 From: Herbert Guan To: Thomas Monjalon CC: "dev@dpdk.org" , "jianbo.liu@linaro.org" , "jerin.jacob@caviumnetworks.com" , "nelio.laranjeiro@6wind.com" Thread-Topic: [dpdk-dev] [PATCH v2] eal/armv8: fix poly64/128 compile issue in old GCC(<4.9.0) Thread-Index: AQHS+34fFVRiSDygZE2HAnyNbQ1I6qJZsbgAgAEkQOCAAEjagIAHlf4w Date: Mon, 24 Jul 2017 10:25:29 +0000 Message-ID: References: <1499856619-21007-1-git-send-email-herbert.guan@arm.com> <11032881.QA85Xq1nMD@xps> <7214394.Gg28SKYvWX@xps> In-Reply-To: <7214394.Gg28SKYvWX@xps> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Herbert.Guan@arm.com; x-originating-ip: [113.29.88.7] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR08MB2811; 7:iteodVGUqzVMczNrc0g3yyKk7YbQNie95kPMTAuE9M4CSi3Xh5j2wiFO/rUSSNzCfI9h28r8zvPuP7Dcm61/gZopQ3fxz/fmX3FJ1htmzQ4JwJpcwkrxYVP/jFW4yvKNwva+gKqnxcjarxkxHWrCQqHL7AdILMe78fTPZmgOimOd11DKi4N1GiM/QuPgUqinlDxgif0Appxw/ktGkJnwyuKMGWJftW8tIq4v6BdP40f7SZ7o8Sb8cx7LrFSIrIx0azQjOD2brM3UA9zfHJ7sAs8i/Rm55zPRusFKw1Dn5YS5pGdFXnNwBz/acUIdqAgnEP+hg1RrOFHzFLzTxCwpvcNW9+Myes3PcAZ2KE9mSpOVwoNewsozBlcSAuv75TSYWVJ0AIbQit1mZ/Nx5pRmCZ/lZtJ1OVeN09fgWO7H3icvUj3aLZ3v3C9fnt47zXTNlsreycJzNT+xsmtZ27yenkHeCdMu+/4ibeWwPacP6N35NGayl7ewx1fnsGys91oMYmXvMuFqywMrXt0Oy6UhRCLIe968cLgULOU+jhpErhAYOav1+aLFFi9tKVf44TPhEyPf7W/GWH2ZmBZAb7855EuuE2yGoUzKjneQ9uLkbV0HUcCh/NBPEnmuTkSysoSOmFqOli2rcw9EKD88yMT1YUFk93tzAMDaFGbwZdlVLd/FU70S6bN0kPLQyNXbhFkYbDFXE9VpnJW7XlFflIVH3zS7rZs6lfIwPmbeWvn2Bc6x8rHozC1grwjyG3TxbJnsfz4iEz4bgHzdgqHPTA2mSNJxKBCrv4lnfRiRlTTCOP0= x-ms-office365-filtering-correlation-id: e800cd85-5a29-459a-5160-08d4d27e4f01 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:HE1PR08MB2811; x-ms-traffictypediagnostic: HE1PR08MB2811: x-exchange-antispam-report-test: UriScan:(180628864354917)(788757137089); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123562025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR08MB2811; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR08MB2811; x-forefront-prvs: 0378F1E47A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39840400002)(39400400002)(39860400002)(39850400002)(39410400002)(199003)(189002)(40434004)(13464003)(8936002)(66066001)(8676002)(2906002)(33656002)(478600001)(68736007)(72206003)(5890100001)(7736002)(7696004)(2900100001)(5250100002)(5660300001)(106356001)(3660700001)(105586002)(3280700002)(54356999)(6916009)(2950100002)(50986999)(76176999)(53546010)(97736004)(25786009)(9686003)(14454004)(54906002)(229853002)(81166006)(74316002)(6436002)(3846002)(101416001)(93886004)(4326008)(6116002)(305945005)(55016002)(189998001)(102836003)(81156014)(53936002)(99286003)(6246003)(86362001)(6506006)(38730400002)(110136004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR08MB2811; H:HE1PR08MB2809.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2017 10:25:29.7279 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR08MB2811 Subject: Re: [dpdk-dev] [PATCH v2] eal/armv8: fix poly64/128 compile issue in old GCC(<4.9.0) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 10:25:32 -0000 "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 vers= ion GCC, this patch is provided. In this way, "rte_v128u8_t" do is having the same definition as poly128_t i= n this patch. But in GCC 4.9.0 and later (e.g. 7.0.0), poly128_t is not in= terpreted 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 AR= M'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_v128= u8_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 Cc: dev@dpdk.org; jianbo.liu@linaro.org; jerin.jacob@caviumnetworks.com; ne= lio.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 confid= ential and may also be privileged. If you are not the intended recipient, p= lease 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.