From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9404 invoked by alias); 16 Jan 2017 17:06:40 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 9376 invoked by uid 89); 16 Jan 2017 17:06:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=BAYES_00,KAM_ASCII_DIVIDERS,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 spammy=Stage, HCC:D*de, H*Ad:U*meissner X-HELO: EUR01-VE1-obe.outbound.protection.outlook.com Received: from mail-ve1eur01on0046.outbound.protection.outlook.com (HELO EUR01-VE1-obe.outbound.protection.outlook.com) (104.47.1.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 16 Jan 2017 17:06:29 +0000 Received: from VI1PR0801MB2031.eurprd08.prod.outlook.com (10.173.74.140) by DB6PR0802MB2613.eurprd08.prod.outlook.com (10.172.252.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Mon, 16 Jan 2017 17:06:26 +0000 Received: from VI1PR0801MB2031.eurprd08.prod.outlook.com ([10.173.74.140]) by VI1PR0801MB2031.eurprd08.prod.outlook.com ([10.173.74.140]) with mapi id 15.01.0845.014; Mon, 16 Jan 2017 17:06:25 +0000 From: Tamar Christina To: Jeff Law , Joseph Myers CC: GCC Patches , Wilco Dijkstra , "rguenther@suse.de" , "Michael Meissner" , nd Subject: Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers in GIMPLE. Date: Mon, 16 Jan 2017 17:06:00 -0000 Message-ID: References: ,, In-Reply-To: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Tamar.Christina@arm.com; x-ms-office365-filtering-correlation-id: 50ee5751-ca04-49b5-425b-08d43e32013d x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB6PR0802MB2613; x-microsoft-exchange-diagnostics: 1;DB6PR0802MB2613;7:vP3uhtuOvdCWjg8XCfqJ8XpMXNPaTnugl3GYHrUGFHndcYG/RmLnNSZosTB1MvYMtZWH9VJblhC8//2+KR2uMDE1Xf1FUtpOPg6Gca6IIaAYrvzY9eikWZmeA12vflAGjIq2SfgdHEjzfOOEmnNUGVKN2IFZx8FCGKFLQM+7VTucJ+Gmso/gPVbBuuwZqIxyaTumeXhZUu8eENFDgrZen7qvIEDXSA6Yn7zAfdgD+ufEZw+Xk7Y3lqhV+AjrEetEgQk2/snV/48sO8H5qY4PuZiFGcx9octUY9q0to031Qpr0Rkpo5nfI4i2SKBm9DVjZ41fs7BTYKt5rTvf9ahF65Dyc218eMQSagkfGJvLS/fa44Jc+gjUo4uqo3iFDsupSi8AmLYBnVfAWgoD4MQkTkNLd966ZgWPaUqAxKnkdR0NAQrNHuS/RQFIbioNLQVeJV/L6lyPuXFeRCVkz0FYDg== nodisclaimer: True x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123558021)(20161123560025)(6072148);SRVR:DB6PR0802MB2613;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0802MB2613; x-forefront-prvs: 01894AD3B8 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(7916002)(39840400002)(39850400002)(39860400002)(39410400002)(39450400003)(51694002)(377454003)(189002)(24454002)(199003)(122556002)(55016002)(33656002)(54356999)(99286003)(6116002)(54906002)(74316002)(3846002)(6436002)(76176999)(50986999)(101416001)(102836003)(25786008)(66066001)(189998001)(5890100001)(3280700002)(7696004)(81166006)(81156014)(2906002)(27001)(4326007)(2950100002)(229853002)(97736004)(9686003)(92566002)(8676002)(8936002)(106356001)(5660300001)(106116001)(105586002)(68736007)(305945005)(3660700001)(38730400001)(77096006)(6506006)(86362001)(2900100001)(93886004)(7736002)(5001770100001);DIR:OUT;SFP:1101;SCL:1;SRVR:DB6PR0802MB2613;H:VI1PR0801MB2031.eurprd08.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A: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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2017 17:06:25.4149 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0802MB2613 X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg01114.txt.bz2 Ping. Does this still have a chance or should I table it till Stage 1 opens= again? Tamar. ________________________________________ From: Tamar Christina Sent: Tuesday, January 3, 2017 9:55:51 AM To: Jeff Law; Joseph Myers Cc: GCC Patches; Wilco Dijkstra; rguenther@suse.de; Michael Meissner; nd Subject: Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbe= rs in GIMPLE. Hi Jeff, I wasn't sure if you saw the updated patch attached to the previous email o= r if you just hadn't had the time to look at it yet. Cheers, Tamar ________________________________________ From: Jeff Law Sent: Monday, December 19, 2016 8:27:33 PM To: Tamar Christina; Joseph Myers Cc: GCC Patches; Wilco Dijkstra; rguenther@suse.de; Michael Meissner; nd Subject: Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbe= rs in GIMPLE. On 12/15/2016 03:14 AM, Tamar Christina wrote: > >> On a high level, presumably there's no real value in keeping the old >> code to "fold" fpclassify. By exposing those operations as integer >> logicals for the fast path, if the FP value becomes a constant during >> the optimization pipeline we'll see the reinterpreted values flowing >> into the new integer logical tests and they'll simplify just like >> anything else. Right? > > Yes, if it becomes a constant it will be folded away, both in the integer= and the fp case. Thanks for clarifying. > >> The old IBM format is still supported, though they are expected to be >> moveing towards a standard ieee 128 bit format. So my only concern is >> that we preserve correct behavior for those cases -- I don't really care >> about optimizing them. So I think you need to keep them. > > Yes, I re-added them. It's mostly a copy paste from what they were in the > other functions. But I have no way of testing it. Understood. >> > + const HOST_WIDE_INT type_width =3D TYPE_PRECISION (type); >>> + return (format->is_binary_ieee_compatible >>> + && FLOAT_WORDS_BIG_ENDIAN =3D=3D WORDS_BIG_ENDIAN >>> + /* We explicitly disable quad float support on 32 bit systems. = */ >>> + && !(UNITS_PER_WORD =3D=3D 4 && type_width =3D=3D 128) >>> + && targetm.scalar_mode_supported_p (mode)); >>> +} >> Presumably this is why you needed the target.h inclusion. >> >> Note that on some systems we even disable 64bit floating point support. >> I suspect this check needs a little re-thinking as I don't think that >> checking for a specific UNITS_PER_WORD is correct, nor is checking the >> width of the type. I'm not offhand sure what the test should be, just >> that I think we need something better here. > > I think what I really wanted to test here is if there was an integer mode= available > which has the exact width as the floating point one. So I have replaced t= his with > just a call to int_mode_for_mode. Which is probably more correct. I'll need to think about it, but would inherently think that int_mode_for_mode is better than an explicit check of UNITS_PER_WORD and typewidth. > >>> + >>> +/* Determines if the given number is a NaN value. >>> + This function is the last in the chain and only has to >>> + check if it's preconditions are true. */ >>> +static tree >>> +is_nan (gimple_seq *seq, tree arg, location_t loc) >> So in the old code we checked UNGT_EXPR, in the new code's slow path you >> check UNORDERED. Was that change intentional? > > The old FP code used UNORDERED and the new one was using ORDERED and nega= ting the result. > I've replaced it with UNORDERED, but both are correct. OK. Just wanted to make sure. jeff