From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112095 invoked by alias); 17 Mar 2017 06:19:45 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 112080 invoked by uid 89); 17 Mar 2017 06:19:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_WEB,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=Hx-languages-length:1549 X-HELO: NAM01-BN3-obe.outbound.protection.outlook.com From: "Sekhar, Ashwin" To: Wilco Dijkstra , "Pinski, Andrew" , Szabolcs Nagy , Ramana Radhakrishnan CC: "libc-alpha@sourceware.org" , nd Subject: Re: [Aarch64] libmvec development status Date: Fri, 17 Mar 2017 06:19:00 -0000 Message-ID: References: authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=cavium.com; x-microsoft-exchange-diagnostics: 1;BN3PR07MB2609;7:lu7mJsW90XVzek10vs1lFDrTpie260dIVXZzm1bmN6TVKpagO7HSk383BEBoRYGDspudBlG6sqdLOQFeoUZLg1TCvC0YrTl7rPwEFtvAd/Ju5qqdfCoFmU/KXEKtMSdbmnphy+01b4DvuNSCLDa6KOJIpzh5nhYem8WLwsdSAAJ1qsuedbVBd/8gTU2yaJfn4457dYRSHXY0356LtAgR02NmJbk0w+EUPaRP6BckhGg0++kos7mDkpqETi6vJb5hC+tA9L4m3fxbZjHVTEib3WtNmJhk3ThHxfck8uFYp35d6QOJrSZxAmVAUUQqOD2rmVEWwdzgDcATivoKe7dmlg== x-forefront-antispam-report: SFV:SKI;SCL:-1SFV:NSPM;SFS:(10009020)(6009001)(39830400002)(39450400003)(39410400002)(24454002)(377454003)(501624003)(53936002)(7696004)(55016002)(6306002)(54906002)(8936002)(99286003)(74316002)(2900100001)(102836003)(5660300001)(3660700001)(9686003)(86362001)(3280700002)(4326008)(6116002)(3846002)(6246003)(122556002)(50986999)(33656002)(189998001)(66066001)(76176999)(54356999)(8676002)(38730400002)(6436002)(7736002)(6506006)(81166006)(229853002)(305945005)(77096006)(2906002)(25786008);DIR:OUT;SFP:1101;SCL:1;SRVR:BN3PR07MB2609;H:BY2PR07MB2421.namprd07.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; x-ms-office365-filtering-correlation-id: 51299ba6-ccba-49f0-a347-08d46cfd9782 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN3PR07MB2609; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(22074186197030)(183786458502308)(231250463719595); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123558025)(20161123564025)(6072148);SRVR:BN3PR07MB2609;BCL:0;PCL:0;RULEID:;SRVR:BN3PR07MB2609; x-forefront-prvs: 0249EFCB0B spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: cavium.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2017 06:19:38.8966 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR07MB2609 X-SW-Source: 2017-03/txt/msg00368.txt.bz2 On Friday 17 March 2017 01:19 AM, Wilco Dijkstra wrote: > Andrew Pinski wrote: > >> The main justification is that Ashwin is working on the libmvec too. >> He has proposed the ABI: >> https://gcc.gnu.org/ml/gcc/2017-03/msg00077.html >> >> Basically I would like this collaboration upstream rather than in the >> private and not on the mailing list. Also delaying upstreaming the >> base support means there will be two versions out there in the wild >> starting soon. This is not a good thing. > > Agreed, there is no point in having 2 ABIs for the same feature. Since ARM has already started working on libmvec, I believe the ABI=20 would already be in place (atleast as a draft). Appreciate if ARM could=20 share the same. > >> I think he means core specific versions. For an example it might make >> sense to have a different version that is specific to ThunderX2 >> CN99xx. There are some specific instructions sequences are faster to >> do on cn99xx compared to other cores. > > My general feeling is that the scope for microarchitecture specific tunin= g is > very limited. Most of the gains are due to (a) having a vector math funct= ion in > the first place, and (b) good algorithm&polynomial. After that you're typ= ically > limited by FMUL/FMA latency with little potential for improvement (eg. us= ing > FMA may be essential to achieve the ULP goal, and the polynomial might ha= ve > been designed for FMA, so changing it would increase the worst-case error, > potentially significantly so). > > Wilco > Ashwin