[{"id":1762030,"web_url":"http://patchwork.ozlabs.org/comment/1762030/","msgid":"","list_archive_url":null,"date":"2017-09-01T23:13:52","subject":"Re: [PATCH] improves exp() and expf() performance on Sparc.","submitter":{"id":4349,"url":"http://patchwork.ozlabs.org/api/people/4349/","name":"Joseph Myers","email":"joseph@codesourcery.com"},"content":"You're defining ifuncs for exp and expf (rather than __ieee754_exp, \n__exp_finite etc. as on x86_64). But you're not doing anything to stop \nthe w_exp_compat / w_expf_compat wrappers from being built that also \ndefine exp and expf, so I don't see how that can work without ending up \nwith multiple definitions of exp and expf; I'd expect you to need to \noverride the wrappers with empty files in such a case of a function \nimplementation with all the error handling integrated.\n\nI'm also concerned that you have local matherr handling which is not \ncompatible with all the cases in __kernel_standard (which are not well \ntested). If you need to have your own integrated error handling for \nperformance reasons, matherr handling should be bug-compatible with the \nexisting code, for both overflow and underflow. (Or define a new symbol \nversion, make the existing exp and expf into compat symbols for SPARC and \nthen your new version only needs to handle errno setting, not matherr.)","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-84119-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"AAopr+ID\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xkZnD73Wgz9sMN\n\tfor ;\n\tSat, 2 Sep 2017 09:14:08 +1000 (AEST)","(qmail 84159 invoked by alias); 1 Sep 2017 23:14:02 -0000","(qmail 84148 invoked by uid 89); 1 Sep 2017 23:14:02 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:cc:subject:in-reply-to:message-id\n\t:references:mime-version:content-type; q=dns; s=default; b=rAnym\n\tEOaqk0M7m7wyItGV54tQJaErXIlAnaKxqZApE2yNai6Ohsbeh47x0MR/2fy7MLdd\n\tK4Zu2MCJQUEZkbPLOGNFa1OCsNc9kvO32Rw4j98CF0Dxrn4rlyGR88AeYhYvVq8V\n\tFuy9EJJs9HbAF0fs8u3xxnzk7t12PAd0OwhpxY=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:cc:subject:in-reply-to:message-id\n\t:references:mime-version:content-type; s=default; bh=bZXTEByt0z9\n\tnqH6WpAi46hrhJVY=; b=AAopr+IDrcd5t/e/7tmJFVA7Ri4KFw/SNsyHswlUwGD\n\tqyZRjR/m5nzsonh0omHSHI/tK5ggEQ0wnRwuTrGk93ZZDh3O682Hc+osnnbgeXN7\n\toTFAVFAkeyI2WrrIvMlnD8mqk+45CqiKiZyC06g2KRScpUGcPhGpqnds6dBSYCxU\n\t=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-2.0 required=5.0 tests=AWL, BAYES_00,\n\tRCVD_IN_DNSWL_NONE, SPF_PASS,\n\tURIBL_RED autolearn=ham version=3.3.2 spammy=Hx-languages-length:1076","X-HELO":"relay1.mentorg.com","Date":"Fri, 1 Sep 2017 23:13:52 +0000","From":"Joseph Myers ","To":"Patrick McGehearty ","CC":"","Subject":"Re: [PATCH] improves exp() and expf() performance on Sparc.","In-Reply-To":"<1504306749-46787-1-git-send-email-patrick.mcgehearty@oracle.com>","Message-ID":"","References":"<1504306749-46787-1-git-send-email-patrick.mcgehearty@oracle.com>","User-Agent":"Alpine 2.20 (DEB 67 2015-01-07)","MIME-Version":"1.0","Content-Type":"text/plain; charset=\"US-ASCII\"","X-ClientProxiedBy":"svr-ies-mbx-02.mgc.mentorg.com (139.181.222.2) To\n\tsvr-ies-mbx-01.mgc.mentorg.com (139.181.222.1)"}},{"id":1762590,"web_url":"http://patchwork.ozlabs.org/comment/1762590/","msgid":"<59AD3C67.3070203@arm.com>","list_archive_url":null,"date":"2017-09-04T11:43:35","subject":"Re: [PATCH] improves exp() and expf() performance on Sparc.","submitter":{"id":65667,"url":"http://patchwork.ozlabs.org/api/people/65667/","name":"Szabolcs Nagy","email":"szabolcs.nagy@arm.com"},"content":"On 01/09/17 23:59, Patrick McGehearty wrote:\n> --- /dev/null\n> +++ b/sysdeps/sparc/fpu/libm_endian.h\n\nis this header useful?\n\n> +#define\tXBIASED_EXP(x)\t((((int *)&x)[HIXWORD] & 0x7fffffff) >> 16)\n> +#define\tISZEROL(x)\t(((((int *)&x)[0] & ~XSGNMSK) | ((int *)&x)[1] | \\\n> +\t\t\t\t((int *)&x)[2] | ((int *)&x)[3]) == 0)\n\ni don't see these used and such aliasing violation\nis not acceptable anyway.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-84159-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"kkpmuJYU\"; dkim-atps=neutral","sourceware.org; auth=none","spf=none (sender IP is )\n\tsmtp.mailfrom=Szabolcs.Nagy@arm.com; "],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xm7KQ52txz9s8J\n\tfor ;\n\tMon, 4 Sep 2017 21:43:54 +1000 (AEST)","(qmail 125813 invoked by alias); 4 Sep 2017 11:43:48 -0000","(qmail 124664 invoked by uid 89); 4 Sep 2017 11:43:47 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:message-id:date:from:mime-version:to:cc\n\t:subject:references:in-reply-to:content-type\n\t:content-transfer-encoding; q=dns; s=default; b=EXapPHYtf8jfP4zt\n\tZRqo7rxOAm3BqVmybNUUfMN+Ph6bk8o14jX7Nb9O4/rkwAZHTay98RP4A/QH05L7\n\tTHNRrRNEyXDKeL3CQ8s32Yx3jv9c7fCEz2jnEptFQZwevvFmKYvjC4WQcF8BTctU\n\tTvSTPp24Whb6crH9EC/CnXZemzg=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:message-id:date:from:mime-version:to:cc\n\t:subject:references:in-reply-to:content-type\n\t:content-transfer-encoding; s=default; bh=9CImDkrRmwDeAemLwBaGXf\n\tuLB+U=; b=kkpmuJYUurQavdnZv7OHf7cltAOhQEdNok5xzUcfhgbKqdHk8/ZFyC\n\t/lvgnE3DnxAeqo+wJ0BCehgxuIPivUbMiXP7qtNRdJgUOgHvlY+DUEG9b+sfx6N9\n\tFkIOY3eba7iAPy5t5QfvTBqllUaF0Vu/s/g8VNz7utzMCByO4dyZQ=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-11.1 required=5.0 tests=AWL, BAYES_00,\n\tGIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS,\n\tSPF_PASS autolearn=ham version=3.3.2 spammy=(unknown),\n\tHx-languages-length:451","X-HELO":"EUR01-DB5-obe.outbound.protection.outlook.com","Message-ID":"<59AD3C67.3070203@arm.com>","Date":"Mon, 04 Sep 2017 12:43:35 +0100","From":"Szabolcs Nagy ","User-Agent":"Mozilla/5.0 (X11; Linux x86_64;\n\trv:31.0) Gecko/20100101 Thunderbird/31.8.0","MIME-Version":"1.0","To":"Patrick McGehearty , \n\tlibc-alpha@sourceware.org","CC":"nd@arm.com","Subject":"Re: [PATCH] improves exp() and expf() performance on Sparc.","References":"<1504306749-46787-1-git-send-email-patrick.mcgehearty@oracle.com>","In-Reply-To":"<1504306749-46787-1-git-send-email-patrick.mcgehearty@oracle.com>","Content-Type":"text/plain; charset=windows-1252","Content-Transfer-Encoding":"7bit","X-ClientProxiedBy":"AM5PR06CA0005.eurprd06.prod.outlook.com\n\t(2603:10a6:206:2::18) To AM5PR0802MB2482.eurprd08.prod.outlook.com\n\t(2603:10a6:203:98::23)","X-MS-PublicTrafficType":"Email","X-MS-Office365-Filtering-Correlation-Id":"8bbc87bb-ee3b-466c-4344-08d4f38a2f48","X-MS-Office365-Filtering-HT":"Tenant","X-Microsoft-Antispam":"UriScan:; BCL:0; PCL:0;\n\tRULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);\n\tSRVR:AM5PR0802MB2482; ","X-Microsoft-Exchange-Diagnostics":["1; AM5PR0802MB2482;\n\t3:kT2pn60J7CWAYT58JdmxQVsAW8MCScNmo54SlpPsqyA8IDAvkgDxVGkESIdmoU5FckftTEpdq2ccuIeYQ3WWT9WXTUZlBIIQ4AI0skvDlxbyYMKZGa7eOZfuwsYldpcP0U5rlAklwTC8GncfZcEcmpioSyKaNMC8hP6LbEEOGg7PwV1A27bT3eIcC8GNFx7vA9OxOi4uFZDRGnLnZfWAx4zKeHzN6tkNF/eVFpJsr2s3kMBgG+X7QtKJd1f5qS+q;\n\t25:JUvxEtmsKDs2zIEoAIktefDHp+i6mbPdyylHCdLDh6CFO4wONoF+k3uMyEvpOvII4JxlcYonZ3x9wsdgH1n0cGs6jYzRQt0nOSEajjpmVhJ0GFVd2b3rrJzAmKUgvuM6iLh7M2aLbXla6BRqqJAyiaX/q7LFtupBtToVmnAUQjMPZSAd21jj4lFHpTdPOqnyhyFw+iqRfqStVi30kvsADLD9QBc7XtuiC1UUcbjMdiwEYIAeYJEmdMBKcOsVZ2sy4YhkFbN/bWdD1RuxAK8jwOktj+sBv5v+UIEowcURuBg79H9ld2C0kb8gO517R2DBFZ4ungL4IkmJ0YXYM5qt6g==;\n\t31:6lVmKxWMiBnVfXDNmi4KnyC3Nk1gctRiARHN6o1rZK73321PFS3xkcFYHVkR81WQc47Bl4P55q2oE2lFR83TeCCGNfoGriKQlKZsrS6+IEps0El9kRylAqXjmB7HpZAddPdpRojU2n3HWq3f6QIHT1hx2Sbn5K7kkoeDvECIXKPtvLZMtIoBXLhm/ASCWpEZLofTQHlLSXE+M9H3ZN0PFEPMQLhJnzlSn9UmZ8Vb4IM=","1; AM5PR0802MB2482;\n\t20:R3wDIWtEqTQ3fVg3ezYt+9HhOGWbtAxQyt5gLI3rSMtBkTtkEB/UNKNgqAiaaN0SBEMlcOCinEGbxHOQI/YKvlOACqNN3O5A48L+fLlGKKhqrArUAkOYBa4d5GjzmwMLZLSAOd14ubixvwG5vyTH+URx+/57pkdTQL0e5fikqz8=;\n\t4:6gbLV8koZmSWpfLWSq/gTK4IWAIXRty2OKYMgtKB99rOxBmc2tYleOnWpwj80cdRnIXGTALTvb9zd5161S+5+dcerrzNFE+JFiF6gHvBrZLR5YiDXPaEJGKRzOCoRCfrLIKofFetJF2NTu25LXtmopjSb+jrKTMx+Y8w2dZoFrLOVJaw9VrUwWucX2chyXPgiPgya0Tc9hiQ4Nr7HXT9IK4qQo4nRcXhHewHCgkP6MTOl2rtdDsUKijXw3rpwAaS","=?windows-1252?q?1=3BAM5PR0802MB2482=3B?=\n\t=?windows-1252?q?23=3AXUMDRRXxsW0bmo/3/Eu9u0CbsiPrOHmOGiJatMBJihWj?=\n\t=?windows-1252?q?HhmCkSHPEd08UvgvesJmWxPJzhnQbIYvo+B7X8bYzpSX7h3hd?=\n\t=?windows-1252?q?Iowjn/STzTI3lyo8KYWMgxXznTZ8+D/s7axYJVIjfEyUwpVPh?=\n\t=?windows-1252?q?t2tW21v/AMyDvVQN8gB95cKPEmc+Jo2NACMpkB/LKuFWHoEbU?=\n\t=?windows-1252?q?FOieo4AYptwrpscP1joemYgt4A2qFSUYjCx80tiBCIxQBkMfD?=\n\t=?windows-1252?q?dsD60QFaMZhCUojwim6f5aW0WzMHpSp5FmD0icHmt6jZw8liS?=\n\t=?windows-1252?q?TPXaMgyqeH0FJcyOxOpuo7vcGb31XxaAA1JKdTYrLWTmfiKR3?=\n\t=?windows-1252?q?FiKXHLrFrph3lJkF9RLs9lgyN5VizlsiUKBGdTiuHbIvd+zoq?=\n\t=?windows-1252?q?fXXUV5d2XVRKLFClGhJ39Bim2Km7AifZoKegxWNuSyIyG7pR5?=\n\t=?windows-1252?q?kKNEasaCgg5EjDKSbzi3ALv5OPsmCaKROzfpcA45nSr5cZ5Qs?=\n\t=?windows-1252?q?+5P3oAcjdCumLEmySGX/GTyHi9qqoom0Z1xICuRuuYAQKkb5s?=\n\t=?windows-1252?q?bYzPVzarWBJh9IIT62GqX1xxrrcoP4hIJmU6eAejLDSymW6sk?=\n\t=?windows-1252?q?JZHbZ0La0TT3kqNxC3xqvnzeFLNtCr3Ko8dje7NoGuFaW9nXc?=\n\t=?windows-1252?q?7aazqOyxofxKheT8hWDt8h1O7ojKSpm18bqwFyrc4iXFRSIPV?=\n\t=?windows-1252?q?R4tIIYZm19zyM875X1HEWuERudpQog1yEmQ2vtO0oL2vqfqOY?=\n\t=?windows-1252?q?N6NnsMgJU8XO5wrsu2O6AcSEN2/YUcyhXFmiUgmu0HGqVsahP?=\n\t=?windows-1252?q?UbGdZawWXKAw7mwE7VcLiN8DNbkGnm09U5IiiD30zkvTTu7Xe?=\n\t=?windows-1252?q?1Uk5CA2xXOB4lN0ip/Xr6w81jkvxR8YjI9UZYNaklHZu0vQcy?=\n\t=?windows-1252?q?zkxjupevOLnTQYReNDir3WLLHcN0ws1rmvRY8Dd0IPtRU5kuL?=\n\t=?windows-1252?q?LypDWpE0O+aIsjDcCo654zwYljJb+zOWur47MiNIGYxh3IwQO?=\n\t=?windows-1252?q?+1pLHZRTETVuY5v9tKtZGQBCqynemunS0WTtlpfMVWfeXrBOP?=\n\t=?windows-1252?q?9EQyQ5nkJ41F3RdMo0xUQMf1NZBur5YxeTvasC6aDaZEc1bkE?=\n\t=?windows-1252?q?AAfY+xOBEFPjDbyoHuBuow7DAtznzqVDpBXefYdhig7ULTUDM?=\n\t=?windows-1252?q?MV6S3L0TR+vnN1IF66O2fY6kp00q2dj8bUMKwSo09hhCnYcCk?=\n\t=?windows-1252?q?ZP0qZp+Q5PZRlxAHIxsU41oK7Vw4WKVSkTls9InjbvrhwBZ4a?=\n\t=?windows-1252?q?upkO3MUDGeXqutIBqzwpfB5FFkTLT1iZEEXdStLIFiS7ppEnX?=\n\t=?windows-1252?q?q3KRCA+vmjCED+kVJchiUzoEupCRifhdNl0nxZoxBMlYC01FA?=\n\t=?windows-1252?q?73l5aP+ooiZpPWERTynpwzFuHRMQ4e+31A2mLB6AP2lyP+PQQ?=\n\t=?windows-1252?q?EGdxaRJ6EnWcqoqmg4OnUtgNcKBCCCQvScABvE56F?=","1; AM5PR0802MB2482;\n\t6:nobLgWijeXsL9ZUOByU6Ju9V88n8H81IqD2n7kwOH4IKJ60XK5hgmgDhxOJnzFNHBtNwJLh0m/40qG8mqPTzm1M+1KCJ9QaZOljC5BeuOIzKDB9ueC0QFctl+7hQswwP+Xqtxm0NWn8us4Hgx6uy3W51ns9BC6jWqw5vuzIAGaweJ5ZVrvFvS9166gGAzfKO8dXHMkSHnD/PSoOfWWDC4ZV843HzD3QG5yxG+3GlfGyT2jo1TjeF5Ia2twdF5Gn43SP+6u1AAr0LsN/JHXMmW/cFb/xykl1ocGiuHokjxfnvbNCW/14CV7308UD3cOoOo0zxlzgS2YSFXEtwp05zBw==;\n\t5:pRHG/gFoXsRSKoacR6/m6SEL1pkuCz5RUl5D/6eB0eCn9Kpj3gWtkvf1ce41f3qtU+dvLQNtzV8t6Md2wviFKCv4e9fvn5946zQCX3x/H3g03L8wkxIBs8Fsmp4tY74D3JFVJRbxBrMpp+nuaMTGLQ==;\n\t24:wgH14R7OqFbQIUuqozwUhCiguKAzYUPeLCWMlbOfmC0nRIj0yzDf0E7lrD5HS04oS2bgWXxkZ+R1nh1uku9ZvEzL8ginny4a6CO8/64allI=;\n\t7:j2V3c3CnUe4PGI4O1P3Qj8nrTlyLsTLi/GPaG7mOqRfGmvOh7pIqO3sM1gCGVLm9TNm7e/LeIZPsVGGOJQXZEBpBFAYxGqxkkSgty0PGBgAlAOH7M2Up/A++93ExFmfIJ2KdwYhebSZLMLp1buKoUGP8iZhinU/cCurxz+qBjlXhFc3aUfTI7eM6iVQN2o9OL4Hh+AepDyRcciTRRwLmjZ5kqeA6O5i1FaUxRCy/HRU="],"X-MS-TrafficTypeDiagnostic":"AM5PR0802MB2482:","NoDisclaimer":"True","X-Exchange-Antispam-Report-Test":"UriScan:;","X-Microsoft-Antispam-PRVS":"","X-Exchange-Antispam-Report-CFA-Test":"BCL:0; PCL:0;\n\tRULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);\n\tSRVR:AM5PR0802MB2482; BCL:0; PCL:0;\n\tRULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);\n\tSRVR:AM5PR0802MB2482; ","X-Forefront-PRVS":"0420213CCD","X-Forefront-Antispam-Report":"SFV:NSPM;\n\tSFS:(10009020)(4630300001)(7370300001)(6009001)(6049001)(39860400002)(189002)(199003)(24454002)(4001350100001)(47776003)(8676002)(59896002)(83506001)(189998001)(65956001)(65806001)(478600001)(66066001)(53546010)(68736007)(64126003)(6116002)(229853002)(72206003)(97736004)(80316001)(77096006)(50466002)(6486002)(25786009)(4326008)(81166006)(81156014)(3846002)(42186005)(7736002)(106356001)(23746002)(87266999)(54356999)(7350300001)(86362001)(230700001)(6246003)(105586002)(2950100002)(305945005)(5660300001)(50986999)(2906002)(33656002)(36756003)(65816999)(76176999)(53936002)(6666003)(101416001)(110136004);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0802MB2482;\n\tH:[10.2.206.69]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1;\n\tLANG:en; ","Received-SPF":"None (protection.outlook.com: arm.com does not designate\n\tpermitted sender hosts)","SpamDiagnosticOutput":"1:99","SpamDiagnosticMetadata":"NSPM","X-OriginatorOrg":"arm.com","X-MS-Exchange-CrossTenant-OriginalArrivalTime":"04 Sep 2017 11:43:38.6165\n\t(UTC)","X-MS-Exchange-CrossTenant-FromEntityHeader":"Hosted","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"AM5PR0802MB2482"}},{"id":1764353,"web_url":"http://patchwork.ozlabs.org/comment/1764353/","msgid":"","list_archive_url":null,"date":"2017-09-06T20:31:05","subject":"Re: [PATCH] improves exp() and expf() performance on Sparc.","submitter":{"id":72081,"url":"http://patchwork.ozlabs.org/api/people/72081/","name":"Patrick McGehearty","email":"patrick.mcgehearty@oracle.com"},"content":"On 9/4/2017 6:43 AM, Szabolcs Nagy wrote:\n> On 01/09/17 23:59, Patrick McGehearty wrote:\n>> --- /dev/null\n>> +++ b/sysdeps/sparc/fpu/libm_endian.h\n> is this header useful?\n>\n>> +#define\tXBIASED_EXP(x)\t((((int *)&x)[HIXWORD] & 0x7fffffff) >> 16)\n>> +#define\tISZEROL(x)\t(((((int *)&x)[0] & ~XSGNMSK) | ((int *)&x)[1] | \\\n>> +\t\t\t\t((int *)&x)[2] | ((int *)&x)[3]) == 0)\n> i don't see these used and such aliasing violation\n> is not acceptable anyway.\n>\nThese definitions are not used in the new exp routines.\nI will remove them from my next submission as well as HIXWORD and XSGNMSK.\nIf later porting of other math routines suggests\nthey might be useful, we can discuss what to do at that time.\n\n- patrick","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-84276-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"fNi1Mztv\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xnZxC3fmvz9t2c\n\tfor ;\n\tThu, 7 Sep 2017 06:31:27 +1000 (AEST)","(qmail 16201 invoked by alias); 6 Sep 2017 20:31:18 -0000","(qmail 13787 invoked by uid 89); 6 Sep 2017 20:31:16 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; q=dns; s=default; b=DN9JXDrf87Pza6Hv\n\tuNXy3Gm7uAEL9py2MxLNqvDEbHQz8hCH/V/0yGYXiqJdM16uAgNEgkM5cJjBbSg0\n\tVmkNsSx1WjEntJak9M13E9APjlUTMvoL8zaTkZY7+HyEGcQGYMoEiJPXK8SGk/Lr\n\tdkCtCCedF3BwORh9huR3Ml8qzfI=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; s=default; bh=k3JsXoA00D1vrGH+YdiLz6\n\tMGFKQ=; b=fNi1Mztv04hWikbOgY7d9s+B0L+VMahj6diXi9zb04RuEwX3Rw5tHe\n\tvgXGZMnOERPE/Vxh5yD1lnYBBQ0TAN/ydLWgmAuCn1jW9OeAalqqk28qNPnfj2W2\n\tv3CW9ArnpGqXetVrhmIm3aYqKbHdBf3jeDxmspK+r5pSYW8gr997E=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-10.9 required=5.0 tests=BAYES_00, GIT_PATCH_2,\n\tGIT_PATCH_3, KAM_LAZY_DOMAIN_SECURITY,\n\tRP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*u:6.3,\n\tH*UA:6.3, H*M:48c0","X-HELO":"userp1040.oracle.com","Subject":"Re: [PATCH] improves exp() and expf() performance on Sparc.","To":"libc-alpha@sourceware.org","References":"<1504306749-46787-1-git-send-email-patrick.mcgehearty@oracle.com>\n\t<59AD3C67.3070203@arm.com>","From":"Patrick McGehearty ","Message-ID":"","Date":"Wed, 6 Sep 2017 15:31:05 -0500","User-Agent":"Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<59AD3C67.3070203@arm.com>","Content-Type":"text/plain; charset=windows-1252; format=flowed","Content-Transfer-Encoding":"7bit"}},{"id":1764356,"web_url":"http://patchwork.ozlabs.org/comment/1764356/","msgid":"","list_archive_url":null,"date":"2017-09-06T20:34:05","subject":"Re: [PATCH] improves exp() and expf() performance on Sparc.","submitter":{"id":72081,"url":"http://patchwork.ozlabs.org/api/people/72081/","name":"Patrick McGehearty","email":"patrick.mcgehearty@oracle.com"},"content":"On 9/1/2017 6:13 PM, Joseph Myers wrote:\n> You're defining ifuncs for exp and expf (rather than __ieee754_exp,\n> __exp_finite etc. as on x86_64). But you're not doing anything to stop\n> the w_exp_compat / w_expf_compat wrappers from being built that also\n> define exp and expf, so I don't see how that can work without ending up\n> with multiple definitions of exp and expf; I'd expect you to need to\n> override the wrappers with empty files in such a case of a function\n> implementation with all the error handling integrated.\nThe sysdeps/ieee754/dbl-64/w_exp_compat.c\ndeclares __exp (double x)\nand then adds:\nhidden_def (__exp)\nweak_alias (__exp, exp)\n\nI believe the weak_alias in w_exp_compat.c is overriden by the\nsparc_libm_ifunc in e_exp-generic.c.  At least, I am not seeing any\nlink time errors about double exp declarations and I am seeing the new\ncode being executed (as proved by the speed and accuracy changes).\n\n>\n> I'm also concerned that you have local matherr handling which is not\n> compatible with all the cases in __kernel_standard (which are not well\n> tested). If you need to have your own integrated error handling for\n> performance reasons, matherr handling should be bug-compatible with the\n> existing code, for both overflow and underflow. (Or define a new symbol\n> version, make the existing exp and expf into compat symbols for SPARC and\n> then your new version only needs to handle errno setting, not matherr.)\n>\nAs for error handling, I believe the extra level of indirection on\nreturn from exp provided by the sysdeps/ieee754/dbl-64/w_exp_compat.c\nroutine is an anti-performance design. Every normal return from e_exp\nrequires an extra level of indirection and several tests/branches that\nshould be bypassed unless an error is detected. The e_exp code already\nchecks for underflow/overflow/NAN/etc. Those unnecessary tests for the\nnon-exceptional cases add overhead for the most frequent uses of exp().\n\nOn the other hand, once an error occurs that triggers__set_err_exp,\nextra overhead is not a significant performance issue. I will add a\ncall __kernel_standard in that routine when _LIB_VERSION is not _IEEE_\nor _POSIX_. As you point out, that will provide more consistent error\nhandling behavior. I'll make that change in my next exp patch\nsubmission.\n\n- patrick","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-84277-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"prU5yfNR\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xnb0Y6V5Vz9t2c\n\tfor ;\n\tThu, 7 Sep 2017 06:34:21 +1000 (AEST)","(qmail 43204 invoked by alias); 6 Sep 2017 20:34:16 -0000","(qmail 41579 invoked by uid 89); 6 Sep 2017 20:34:15 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:cc:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; q=dns; s=default; b=khuEUr8PxsQVqQte\n\t65htYVl9SHiUdgmIWr6NX61pRp7Xnr1WbOhAZ9OcagST17Rr1TfjaEdBF1vLWUbn\n\t3wTzYN+mmVbhP2j805/P/nHeJi3ggykAnguBgTdhi9mpOiuZYxhNdzO4knx/54dy\n\tB+sL33/GDNQ95d6oSHdR5ifVn6w=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:cc:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; s=default; bh=sg4T8SODpejT0mcWVxYegw\n\tAnlm8=; b=prU5yfNRzGvnHRONCJTnSdN9UXggbtY915TVG0cpHfaAB+UOjwGDEa\n\t8oJ4ylmts3XRb1RD0QySaMkmDLLRYzeIleNE8Bpy3mdjtRciFNImGsFRztKJlSBF\n\tqmFezpdHFH1GjNQRDPFdJhL6I0T8cUlmDYc7/YLgLoqu5+y9Tkrl4=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-0.9 required=5.0 tests=BAYES_00,\n\tKAM_LAZY_DOMAIN_SECURITY,\n\tRP_MATCHES_RCVD autolearn=no version=3.3.2\n\tspammy=Hx-languages-length:2356, H*u:6.3, H*UA:6.3,\n\tHContent-Transfer-Encoding:8bit","X-HELO":"userp1040.oracle.com","Subject":"Re: [PATCH] improves exp() and expf() performance on Sparc.","To":"Joseph Myers ","Cc":"libc-alpha@sourceware.org","References":"<1504306749-46787-1-git-send-email-patrick.mcgehearty@oracle.com>\n\t","From":"Patrick McGehearty ","Message-ID":"","Date":"Wed, 6 Sep 2017 15:34:05 -0500","User-Agent":"Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"8bit"}},{"id":1764375,"web_url":"http://patchwork.ozlabs.org/comment/1764375/","msgid":"","list_archive_url":null,"date":"2017-09-06T21:01:00","subject":"Re: [PATCH] improves exp() and expf() performance on Sparc.","submitter":{"id":4349,"url":"http://patchwork.ozlabs.org/api/people/4349/","name":"Joseph Myers","email":"joseph@codesourcery.com"},"content":"On Wed, 6 Sep 2017, Patrick McGehearty wrote:\n\n> The sysdeps/ieee754/dbl-64/w_exp_compat.c\n> declares __exp (double x)\n> and then adds:\n> hidden_def (__exp)\n> weak_alias (__exp, exp)\n> \n> I believe the weak_alias in w_exp_compat.c is overriden by the\n> sparc_libm_ifunc in e_exp-generic.c.  At least, I am not seeing any\n> link time errors about double exp declarations and I am seeing the new\n> code being executed (as proved by the speed and accuracy changes).\n\nThen you should avoid any object code from w_exp_compat.c being linked \ninto libm.so at all, by overriding it with a dummy file, rather than just \nletting certain symbols be overridden at link time.\n\n> As for error handling, I believe the extra level of indirection on\n> return from exp provided by the sysdeps/ieee754/dbl-64/w_exp_compat.c\n> routine is an anti-performance design. Every normal return from e_exp\n\nIt's fairly clearly a design optimized for consistency of error handling \nin the presence of several architecture-specific implementations of the \nmain function, without needing to e.g. deal with TLS in assembly code for \naccessing errno or make multiple implementations handle matherr the same \nway. When you avoid architecture-specific implementations (especially .S \nones) as far as possible, integrated error handling is more practical, \nespecially if you also use new symbol versions to avoid needing to deal \nwith matherr.\n\nFor expf performance obviously needs to be compared with Szabolcs's \nimplementation (compiled with whatever options and configured \nappropriately regarding conversions to integer etc. to be optimal for \nSPARC). For exp, I'm inclined to say performance should be compared with \nthe existing exp *with the slow paths calling __slowexp removed along with \nthe associated checks for whether to use those slow paths* since those \nslow paths are completely unnecessary.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-84278-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"RfQ764wJ\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xnbc30cw3z9s7C\n\tfor ;\n\tThu, 7 Sep 2017 07:01:38 +1000 (AEST)","(qmail 54421 invoked by alias); 6 Sep 2017 21:01:25 -0000","(qmail 47589 invoked by uid 89); 6 Sep 2017 21:01:12 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:cc:subject:in-reply-to:message-id\n\t:references:mime-version:content-type; q=dns; s=default; b=POupq\n\tZHP7QnoSOV9xNqyuD0AwB6FP6owEtR7zZHBtbTnLxy6kceoer8IiOE80XgsrSB4z\n\tu1/7h9hMuDchHNTKoWcX5NYXY9+0AU3dwHJK30Kn9fCwZridgITwt6hdt/jr3GXC\n\tdIgk1mn6W351yE5IPL199mkjmOb6ypbQ0a5DXQ=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:cc:subject:in-reply-to:message-id\n\t:references:mime-version:content-type; s=default; bh=BObku9ht4y4\n\tLZBBVf3CkNvhEWk8=; b=RfQ764wJ99tUn/Oag6W5uG8Bx49rMbFKifnUHOPCVpu\n\tEgBqo9gV3mAaxSZUPvCGsW/soYi7YsBR4Iu6S9WP6O5oRUGbIOjoQhS2QIVh1gGa\n\tiki26CteHC22r8QhOZdG4jGD4iGz3hB+k8LqYreGWRcH+at70exP6D9USOLBuPiw\n\t=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-2.0 required=5.0 tests=AWL, BAYES_00,\n\tRCVD_IN_DNSWL_NONE, SPF_PASS,\n\tURIBL_RED autolearn=ham version=3.3.2 spammy=Hx-languages-length:1960,\n\tH*c:HHHHH","X-HELO":"relay1.mentorg.com","Date":"Wed, 6 Sep 2017 21:01:00 +0000","From":"Joseph Myers ","To":"Patrick McGehearty ","CC":"","Subject":"Re: [PATCH] improves exp() and expf() performance on Sparc.","In-Reply-To":"","Message-ID":"","References":"<1504306749-46787-1-git-send-email-patrick.mcgehearty@oracle.com>\n\t\n\t","User-Agent":"Alpine 2.20 (DEB 67 2015-01-07)","MIME-Version":"1.0","Content-Type":"multipart/mixed;\n\tboundary=\"-1152306461-1775032641-1504731660=:29155\"","X-ClientProxiedBy":"svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To\n\tsvr-ies-mbx-01.mgc.mentorg.com (139.181.222.1)"}},{"id":1764935,"web_url":"http://patchwork.ozlabs.org/comment/1764935/","msgid":"<706fe477-8d85-47d9-d62c-164bba5606ec@oracle.com>","list_archive_url":null,"date":"2017-09-07T20:42:23","subject":"Re: [PATCH] improves exp() and expf() performance on Sparc.","submitter":{"id":72081,"url":"http://patchwork.ozlabs.org/api/people/72081/","name":"Patrick McGehearty","email":"patrick.mcgehearty@oracle.com"},"content":"On 9/6/2017 4:01 PM, Joseph Myers wrote:\n> On Wed, 6 Sep 2017, Patrick McGehearty wrote:\n>\n>> The sysdeps/ieee754/dbl-64/w_exp_compat.c\n>> declares __exp (double x)\n>> and then adds:\n>> hidden_def (__exp)\n>> weak_alias (__exp, exp)\n>>\n>> I believe the weak_alias in w_exp_compat.c is overriden by the\n>> sparc_libm_ifunc in e_exp-generic.c.  At least, I am not seeing any\n>> link time errors about double exp declarations and I am seeing the new\n>> code being executed (as proved by the speed and accuracy changes).\n> Then you should avoid any object code from w_exp_compat.c being linked\n> into libm.so at all, by overriding it with a dummy file, rather than just\n> letting certain symbols be overridden at link time.\n>\n>> As for error handling, I believe the extra level of indirection on\n>> return from exp provided by the sysdeps/ieee754/dbl-64/w_exp_compat.c\n>> routine is an anti-performance design. Every normal return from e_exp\n> It's fairly clearly a design optimized for consistency of error handling\n> in the presence of several architecture-specific implementations of the\n> main function, without needing to e.g. deal with TLS in assembly code for\n> accessing errno or make multiple implementations handle matherr the same\n> way. When you avoid architecture-specific implementations (especially .S\n> ones) as far as possible, integrated error handling is more practical,\n> especially if you also use new symbol versions to avoid needing to deal\n> with matherr.\n>\n> For expf performance obviously needs to be compared with Szabolcs's\n> implementation (compiled with whatever options and configured\n> appropriately regarding conversions to integer etc. to be optimal for\n> SPARC). For exp, I'm inclined to say performance should be compared with\n> the existing exp *with the slow paths calling __slowexp removed along with\n> the associated checks for whether to use those slow paths* since those\n> slow paths are completely unnecessary.\n>\nThe sysdeps/ieee_754 subtree has a number of direct calls into\nieee754_exp from such places as e_sinh, e_cosh, e_gamma_r, and s_erf.\nWhile I have not found direct calls to __exp in the ieee_754 subtree,\nI see overriding w_exp_compat.c as having some risk of\nunexpected behavior with the only perceived benefit to be eliminating\na modest number of bytes from libm.\n\nFor exp, when I test isolated values, the factor of improvement\nbetween ieee754 and the new code on Sparc to be in the range of 8x to\n14x. That's not considering cases which trigger slowexp().\n\nComparing the \"make bench\" benchtests/bench.out for exp():\n      ieee754    new\nmax:  17630     174\nmin:    399      26\nmean:  5320      67\n\nWhen the differences are this large and the new max is faster than the\nold min, I don't see a need in doing further performance testing.\n\nFor expf, the comparison for individual values shows an improvement\nin the range of 15x. benchtests does not measure expf().\nMaking this change will provide a clear, immediate gain in expf()\nperformance.\n\nIs the Szabolcs code in its final form?  There were some discussion\nof accuracy and of possible changes to the algorithm, perhaps using\na larger table. The Sparc code uses a larger table and thus may\nbe more accurate for some ulp sensitive values. Or it may be a non-issue\nsince both algorithms are using double precision for computation.\n\nWilco Dijkstra compared the new Sparc code to Szabolcs code on\naarch64 and found Szabolcs code to be 10% faster on aarch64.\nThat advantage may or may not be reversed on Sparc, but it is\nclose enough to justify testing.\nIn addition to a performance comparison, we'd want to do an\naccuracy comparison to see what differences we might be accepting.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-84313-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"MmZqjCON\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpC7r4lX1z9sBW\n\tfor ;\n\tFri, 8 Sep 2017 06:42:48 +1000 (AEST)","(qmail 112874 invoked by alias); 7 Sep 2017 20:42:40 -0000","(qmail 111869 invoked by uid 89); 7 Sep 2017 20:42:40 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:cc:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; q=dns; s=default; b=mqL5/UIZvKWdqM4M\n\tPWujBof2NMPrQeXDt7OtOt/MKoE1Bc65ExIrCE+Cd9Ao3B3/mPoUTTU7Bno1yOQE\n\t6/E6okvsnE/A/oDsvh4Ba4FwAfrZFCeFxYXHDYSLvsjoo4aJZ+DnqL9QldG1YdJQ\n\t95fYpNhQiJZ/B0U1PrH+c089Zgo=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:cc:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; s=default; bh=wIAlrjG8c5dg990ZCmSZ7c\n\tM0ZZk=; b=MmZqjCONAXlqEva4lxYH4kTxttyUPjB8IjVjLf1Siq4dEMXR86fVZO\n\tDGwOZQg9vlOoYqG98Y+c+UgZrEp4OWVk/cL+j4Yk1mOKYvWCxv9cAtpsuh9FIJ6g\n\ttDdz2Cl5Hi6ZaCzhT54T4ctZsAZO+Fdt3Jh2xwVHDbV5W6B/2xL2k=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-0.4 required=5.0 tests=BAYES_00,\n\tKAM_LAZY_DOMAIN_SECURITY, RCVD_IN_SORBS_SPAM,\n\tRP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=H*u:6.3,\n\tH*UA:6.3","X-HELO":"aserp1040.oracle.com","Subject":"Re: [PATCH] improves exp() and expf() performance on Sparc.","To":"Joseph Myers ","Cc":"libc-alpha@sourceware.org","References":"<1504306749-46787-1-git-send-email-patrick.mcgehearty@oracle.com>\n\t\n\t\n\t","From":"Patrick McGehearty ","Message-ID":"<706fe477-8d85-47d9-d62c-164bba5606ec@oracle.com>","Date":"Thu, 7 Sep 2017 15:42:23 -0500","User-Agent":"Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"8bit"}},{"id":1764942,"web_url":"http://patchwork.ozlabs.org/comment/1764942/","msgid":"","list_archive_url":null,"date":"2017-09-07T21:05:21","subject":"Re: [PATCH] improves exp() and expf() performance on Sparc.","submitter":{"id":4349,"url":"http://patchwork.ozlabs.org/api/people/4349/","name":"Joseph Myers","email":"joseph@codesourcery.com"},"content":"On Thu, 7 Sep 2017, Patrick McGehearty wrote:\n\n> The sysdeps/ieee_754 subtree has a number of direct calls into\n> ieee754_exp from such places as e_sinh, e_cosh, e_gamma_r, and s_erf.\n> While I have not found direct calls to __exp in the ieee_754 subtree,\n> I see overriding w_exp_compat.c as having some risk of\n> unexpected behavior with the only perceived benefit to be eliminating\n> a modest number of bytes from libm.\n\nThose direct calls don't use the wrapper and so are completely irrelevant \nto the matter of overriding it.\n\nIt is quite clear that the wrapper needs to be overridden on any \narchitecture providing its own exp (as opposed to __ieee754_exp) \nimplementation, just as ia64 overrides it.\n\n> For expf, the comparison for individual values shows an improvement\n> in the range of 15x. benchtests does not measure expf().\n\nPresumably you need to test with the benchmark addition Szabolcs points to \nin his patch submission.\n\n> Making this change will provide a clear, immediate gain in expf()\n> performance.\n\nMaintainability is also important, and it points against having lots of \narchitecture-specific versions. Thus, people interested in expf \noptimization should first be helping with the review of Szabolcs's patch \n(and the benchtests addition patch it builds on). Once that's done, it \ncan provide a basis for judging the merits of architecture-specific expf \nversions (which might well also indicate improvements to Szabolcs's code \nas an alternative to adding an architecture-specific version).\n\nFor exp, when you have a better-performing C version the question should \nfirst be whether it can replace the existing generic C version (possibly \nthen being built multiple times on architectures where that's useful) \nrather than whether to add it as architecture-specific code. Adding a C \nversion as architecture-specific code (rather than having limited \narchitecture-specific hooks in a generic version) should only be once \nthere is evidence of different architectures' performance characteristics \nrequiring substantially different approaches.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-84315-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"sT9Mszzr\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpCfG6wR5z9s7C\n\tfor ;\n\tFri, 8 Sep 2017 07:05:42 +1000 (AEST)","(qmail 11528 invoked by alias); 7 Sep 2017 21:05:37 -0000","(qmail 11171 invoked by uid 89); 7 Sep 2017 21:05:36 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:cc:subject:in-reply-to:message-id\n\t:references:mime-version:content-type; q=dns; s=default; b=cr/1i\n\tCx1QTrv5QPM2h4h6Tx4B9+FT110OEFS7CCcDvRWxY0YYjuyYXDmRl+fCDEC5XNx3\n\tEOQbryi0H5xJDfQ9vAlXLhNkBuXtxDTqeC6boJqG7zKP4gYgwCYh3WNd8+R9kClE\n\tfGyon5bc087tePZVQMvJhtV0sOnxWZ1CQo6UUQ=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:date:from:to:cc:subject:in-reply-to:message-id\n\t:references:mime-version:content-type; s=default; bh=oxCLwI7JOcU\n\tjiIic5USy79dIi2k=; b=sT9MszzrRqhqUD/gIJtdwOTTK2cGDNSABECHGmjkKIL\n\tASLKQ4qJxDHoj/8YVrWapXg8CvVkDCOUztqSx9Hvr/OtWYy8lufCFse9T2PXTi8e\n\t0Z3iIRV1/Npt9DVq9uZrWs+lLiBJt8+yb9nJp1gSHlSfRCLGMvWNEjhi6rshcPS0\n\t=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-2.0 required=5.0 tests=AWL, BAYES_00,\n\tRCVD_IN_DNSWL_NONE, SPF_PASS,\n\tURIBL_RED autolearn=ham version=3.3.2 spammy=his, risk","X-HELO":"relay1.mentorg.com","Date":"Thu, 7 Sep 2017 21:05:21 +0000","From":"Joseph Myers ","To":"Patrick McGehearty ","CC":"","Subject":"Re: [PATCH] improves exp() and expf() performance on Sparc.","In-Reply-To":"<706fe477-8d85-47d9-d62c-164bba5606ec@oracle.com>","Message-ID":"","References":"<1504306749-46787-1-git-send-email-patrick.mcgehearty@oracle.com>\n\t\n\t\n\t\n\t<706fe477-8d85-47d9-d62c-164bba5606ec@oracle.com>","User-Agent":"Alpine 2.20 (DEB 67 2015-01-07)","MIME-Version":"1.0","Content-Type":"text/plain; charset=\"US-ASCII\"","X-ClientProxiedBy":"svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To\n\tsvr-ies-mbx-01.mgc.mentorg.com (139.181.222.1)"}},{"id":1765003,"web_url":"http://patchwork.ozlabs.org/comment/1765003/","msgid":"<9ec36391-8fca-bdfa-a7a9-4d715e62c568@oracle.com>","list_archive_url":null,"date":"2017-09-07T23:52:49","subject":"Re: [PATCH] improves exp() and expf() performance on Sparc.","submitter":{"id":72081,"url":"http://patchwork.ozlabs.org/api/people/72081/","name":"Patrick McGehearty","email":"patrick.mcgehearty@oracle.com"},"content":"On 9/7/2017 4:05 PM, Joseph Myers wrote:\n> On Thu, 7 Sep 2017, Patrick McGehearty wrote:\n>\n>> The sysdeps/ieee_754 subtree has a number of direct calls into\n>> ieee754_exp from such places as e_sinh, e_cosh, e_gamma_r, and s_erf.\n>> While I have not found direct calls to __exp in the ieee_754 subtree,\n>> I see overriding w_exp_compat.c as having some risk of\n>> unexpected behavior with the only perceived benefit to be eliminating\n>> a modest number of bytes from libm.\n> Those direct calls don't use the wrapper and so are completely irrelevant\n> to the matter of overriding it.\n>\n> It is quite clear that the wrapper needs to be overridden on any\n> architecture providing its own exp (as opposed to __ieee754_exp)\n> implementation, just as ia64 overrides it.\n>\n>> For expf, the comparison for individual values shows an improvement\n>> in the range of 15x. benchtests does not measure expf().\n> Presumably you need to test with the benchmark addition Szabolcs points to\n> in his patch submission.\n>\n>> Making this change will provide a clear, immediate gain in expf()\n>> performance.\n> Maintainability is also important, and it points against having lots of\n> architecture-specific versions. Thus, people interested in expf\n> optimization should first be helping with the review of Szabolcs's patch\n> (and the benchtests addition patch it builds on). Once that's done, it\n> can provide a basis for judging the merits of architecture-specific expf\n> versions (which might well also indicate improvements to Szabolcs's code\n> as an alternative to adding an architecture-specific version).\n>\n> For exp, when you have a better-performing C version the question should\n> first be whether it can replace the existing generic C version (possibly\n> then being built multiple times on architectures where that's useful)\n> rather than whether to add it as architecture-specific code. Adding a C\n> version as architecture-specific code (rather than having limited\n> architecture-specific hooks in a generic version) should only be once\n> there is evidence of different architectures' performance characteristics\n> requiring substantially different approaches.\n>\n\n\nThe sysdeps/ieee_754 subtree has a number of direct calls into\nieee754_exp from such places as e_sinh, e_cosh, e_gamma_r, and s_erf.\nWhile I have not found direct calls to __exp in the ieee_754 subtree,\nI see overriding w_exp_compat.c as having some risk of\nunexpected behavior with the only perceived benefit to be eliminating\na modest number of bytes from libm.\n\nAs for exp performance, when I test isolated values, the factor of\nimprovement between ieee754 and the new code on Sparc to be in the\nrange of 8x to 14x. That's not considering cases which trigger\nslowexp().\n\nComparing the \"make bench\" benchtests/bench.out for exp():\n      ieee754    new\nmax:  17630     174\nmin:    399      26\nmean:  5320      67\n\nWhen the differences are this large and the new max is faster than the\nold min, I don't see a need in doing further performance testing.\n\nMoving on to expf, the comparison for individual values shows an\nimprovement in the range of 15x. benchtests does not measure expf().\nMaking this change will provide a clear, immediate gain in expf()\nperformance.\n\nThe Szabolcs code appears to provide similar benefits.  There were\nsome discussion of accuracy and of possible changes to the algorithm,\nperhaps by using a larger table. The Sparc code uses a larger table and\nthus may be more accurate for some ulp sensitive values. Or it may be\na non-issue since both algorithms are using double precision for\ncomputation.\n\nWilco Dijkstra compared the new Sparc code to Szabolcs code on aarch64\nand found Szabolcs code to be 10% faster on aarch64.  That result is\nclose enough to justify testing on Sparc. In addition to a performance\ncomparison, we'd want to compare accuracy to see if there are notable\ndifferences.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-84369-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"Ona76dMv\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpHMX3kJTz9s7h\n\tfor ;\n\tFri, 8 Sep 2017 09:53:12 +1000 (AEST)","(qmail 63993 invoked by alias); 7 Sep 2017 23:53:04 -0000","(qmail 63232 invoked by uid 89); 7 Sep 2017 23:53:04 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; q=dns; s=default; b=E3q2pp5SGsD+ofJv\n\tMztNd631v8MaqFZKa63P5MLNr4Yc1lGvPQ9sN7V3PlPbgr/gXG7AJ9Mb7XjEuKZF\n\toFqguJfPUwMAloeinVa80m+zab1RqLQ+MzelZZuH3copB0XmVc16I2bXrdkqW/M/\n\tcKBX3Gx9+cHeBogTw0Z1X65Sg7M=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; s=default; bh=3o0PlKJtT1ttQMxNadFfrX\n\tgMHH4=; b=Ona76dMvkS28aqC43ny6QGZlO0NoC2nS/E8pOtDnm2evcHCP0BKsIW\n\tXUlA9DTg9K4F998dzPt3VJ3pgKBCVH/wdw2Ru/nPxwQSZQWQD4XgkR0ocMvY80la\n\tUucaxuul8pXXihcX/HPQjB+ctR0SQL9Yon3I87BfdniW4Y2P092CQ=","Mailing-List":"contact libc-alpha-help@sourceware.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Subscribe":"","List-Archive":"","List-Post":"","List-Help":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-0.9 required=5.0 tests=BAYES_00,\n\tKAM_LAZY_DOMAIN_SECURITY,\n\tRP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=H*u:6.3,\n\tH*UA:6.3, his, risk","X-HELO":"userp1040.oracle.com","Subject":"Re: [PATCH] improves exp() and expf() performance on Sparc.","To":"libc-alpha@sourceware.org","References":"<1504306749-46787-1-git-send-email-patrick.mcgehearty@oracle.com>\n\t\n\t\n\t\n\t<706fe477-8d85-47d9-d62c-164bba5606ec@oracle.com>\n\t","From":"Patrick McGehearty ","Message-ID":"<9ec36391-8fca-bdfa-a7a9-4d715e62c568@oracle.com>","Date":"Thu, 7 Sep 2017 18:52:49 -0500","User-Agent":"Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"8bit"}}]