From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82829 invoked by alias); 3 Jan 2017 09:56:06 -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 82812 invoked by uid 89); 3 Jan 2017 09:56:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=exposing, Hx-spam-relays-external:15.01.0817.009, H*r:15.01.0817.009, H*RU:15.01.0817.009 X-HELO: EUR01-DB5-obe.outbound.protection.outlook.com Received: from mail-db5eur01on0074.outbound.protection.outlook.com (HELO EUR01-DB5-obe.outbound.protection.outlook.com) (104.47.2.74) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 03 Jan 2017 09:55:55 +0000 Received: from VI1PR0801MB2031.eurprd08.prod.outlook.com (10.173.74.140) by AM5PR0802MB2611.eurprd08.prod.outlook.com (10.175.46.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.817.10; Tue, 3 Jan 2017 09:55:52 +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.0817.009; Tue, 3 Jan 2017 09:55:51 +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: Tue, 03 Jan 2017 09:56:00 -0000 Message-ID: References: , In-Reply-To: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Tamar.Christina@arm.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-office365-filtering-correlation-id: 2345ae9a-d650-4afb-fb41-08d433beb393 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM5PR0802MB2611; x-microsoft-exchange-diagnostics: 1;AM5PR0802MB2611;7:Ldf0MCuMHSg3v9DNPf7pq25wHjdHrC8MR/46bhYFCMqPEg9VnDk//kR+8YK6I61Wo+Zp7ZCvwlV5S251N/NkO60Kkx3lv0CTOAS1wxx+kyxTHR93OFHO6jum/UPkwQc4rOOyMkghmq7WA+Nq+eyhTzBU7X9eQ3mZVdycia0q9qYGacFTC8NGXUmPoM4YcjTf7BqqBaXghxn/t9hlmVq7vZExQXvaoQfTsArM2ajC8Dl2Mt+XC3o7OM4xeYCvpPq0zy8/c5gBi40iTlwix4NGGCu9rhn/0fx9USsmzo00aP5vYAo+d2LgLH353EAVAW4S1sJTPbjiJ3y+11a8hiPyRu507T6dbdaU8cvvEHftTEntSy7J4Q0uA1CcYP56givbePkOMJpt1KGAoz6XxYkiQ7fvOytObsSKcBW+tUCPFKjIIRMionc05wynpqHeKHMRkWnNzgqMzFcBlVuTvjmf8Q== 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)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148);SRVR:AM5PR0802MB2611;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0802MB2611; x-forefront-prvs: 01762B0D64 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(7916002)(39450400003)(39850400002)(39840400002)(39410400002)(24454002)(377454003)(189002)(199003)(51694002)(97736004)(9686002)(33656002)(3280700002)(6506006)(25786008)(68736007)(106356001)(5890100001)(2900100001)(105586002)(74316002)(106116001)(305945005)(77096006)(66066001)(3660700001)(55016002)(92566002)(86362001)(38730400001)(81156014)(229853002)(81166006)(54906002)(102836003)(4326007)(8676002)(7736002)(6116002)(189998001)(5001770100001)(93886004)(2950100002)(2906002)(54356999)(76176999)(50986999)(99286003)(6436002)(101416001)(3846002)(122556002)(7696004)(8936002)(5660300001);DIR:OUT;SFP:1101;SCL:1;SRVR:AM5PR0802MB2611;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: 03 Jan 2017 09:55:51.3032 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0802MB2611 X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg00065.txt.bz2 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