From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) by sourceware.org (Postfix) with ESMTPS id E463C3858401 for ; Mon, 5 Aug 2024 14:29:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E463C3858401 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E463C3858401 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::12c ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1722868175; cv=none; b=CI8Dvi9otx4YkZnK9orSIfEpjFTBvttSEORTdrTn0hOYobM/PaSgFA84LzLhyCmHr+SylBGaWAYc3IY+WScNrpbDkJCuszGyfPYGB0u3tmy4ly/dwXtgXZUgsjfLULgADUDJZblPRPt0b8g9Pu7qE3BDMmzrv8mWtGKe9p7pYkc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1722868175; c=relaxed/simple; bh=5bTF4cjeuwE5U93USMEurSW9NHhN5XuDrxv2Ow+2wvI=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=GMmUdZX3x8akBawtUzkXGvIXFluwF8Mc2BE58NZ+ftG5Pf9r5ve2Cy1cBPIb1siC63aD0wMlHGQuy5c1OcAdg9CDrqcul+HhdUvmmoTgBPxHPpEMS24rKKVFN1/QVEVx+kuDhVxS8T4QQMDzm9/oNheLMswEjT4gnNKVu61VxlE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-il1-x12c.google.com with SMTP id e9e14a558f8ab-39adbfafde5so37101565ab.0 for ; Mon, 05 Aug 2024 07:29:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722868172; x=1723472972; darn=gcc.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=mZ4YICT4tfHVfiIqAtocrO2cgPTJZQIZjDKjmTOhK7Y=; b=XT04QMioyowP5X/J+YXNWA3uCM2GIGYN6/tsYEb0AQ1XlTkbfn5vnZ7l8pplrlVSNm vyTXW3DXSTtQZoZ0HMZ6u1ug8ea4UiNo4y3B4aV7kMKYxp1cgtQcfWAql5oXbOUr2IvX WE9AGjoh+8/TikCUN+82yHWkgq3uzkb25cCGhhAkHkcT5xrl5UfIdMKwjJxfWvIRGQyZ qIJQqu3wQD9GKOA/Tmj82HfszquI/te2UQa7ATDTsTXxEixjfB2hPXGmW0U+cx4q2SQg lqgQsdc5uPDtZBPwpi6K1mtUAZQTEZ+3LZBHD46BSGMgi5wOoHX1mhmDdbv+67bcNOEt lVBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722868172; x=1723472972; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mZ4YICT4tfHVfiIqAtocrO2cgPTJZQIZjDKjmTOhK7Y=; b=KOQvuuamSFJxv5G8Mcc+NYo+S/DVZWp4Oys8UDGiB0zo0KBrEG09fhEbZs4Y7dXcd1 03q5FxcYPpj5oXNZSfPZnmuTB4pTuFZNxu3A+Zj1kpac4rOISZr9rmjRZT+yPJLmfdNv ENRBnRnSMkSLoqY1JvQ+9tPJ3P4/+H73zQtqtb+IcI+PjEfiLQTvPywVfrWK7kx6fOkV dA1I+sX3N7egCkDrMdq36KL1LhRExAHoRcBeEHsQ6dJjWj/AN2IW5Jgp0ZNRfkRipXLh K7ATK89GFOBB2S/fvM0Nr2DDmhJyYZFQ/eL90CFxBgiOnAIscjx5vmqZyJtIaa1TLUd2 K6dw== X-Forwarded-Encrypted: i=1; AJvYcCVcbPjEX2jrFKwF24uHWrOstEcgWN4FPA0ViXJXqrzNhKF3IHjaX7V6IiJYFCYuBR+dcNirqSLh49TkHzvJ7Dw7WgZkzoY5wQ== X-Gm-Message-State: AOJu0YyiLYjIYwrNlUgFMQBPRV3U0oVMlBS9vc/RqTiZuxqiAlfaEZY1 vJs63HEPz5k0F5hCyRCctYz7PZXM767ob+E26YJ6WY9w9lhpX8lm X-Google-Smtp-Source: AGHT+IHLXjOixxj7t76KJ1mb3nQKEwrRjTFYjm/dT5CI1HqmFdunDNKfa72+3WLRrjDEHJla1J0diA== X-Received: by 2002:a92:ca83:0:b0:398:54dc:1408 with SMTP id e9e14a558f8ab-39b1fc366c4mr114744585ab.23.1722868172005; Mon, 05 Aug 2024 07:29:32 -0700 (PDT) Received: from [172.31.0.109] ([136.36.72.243]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-7b763a3fa2asm5551524a12.50.2024.08.05.07.29.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Aug 2024 07:29:31 -0700 (PDT) Message-ID: Date: Mon, 5 Aug 2024 08:29:25 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [PATCH] PR tree-optimization/57371: Optimize (float)i == 16777222.0f sometimes. Content-Language: en-US To: Roger Sayle , gcc-patches@gcc.gnu.org Cc: 'Joseph Myers' References: <002e01dae0e5$e4a45b00$aded1100$@nextmovesoftware.com> From: Jeff Law In-Reply-To: <002e01dae0e5$e4a45b00$aded1100$@nextmovesoftware.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 7/28/24 6:01 AM, Roger Sayle wrote: > > This patch improves the tree-level optimization of (fptype)ivar != CST > in match.pd (historically tracked under PR 57371). Joseph Myers' > description in comment #1 provides an excellent overview of the issues, > that historically it's the trapping behaviour of (fptype)ivar conversion > that is the primary concern, which is why the current code in match.pd > checks fmt.can_represent_integral_type_p (itype). The first of the > improvements with this patch is to check flag_trapping_math to control > whether FP_OVERFLOW/FP_INEXACT needs to be preserved, and to use > ranger to determine whether the bounds on ivar confirm that these > traps aren't possible. For example, the expression (int)var & 15 > can't overflow conversion to IEEE float, even though the type of a > 32-bit int could potentially overflow the significant of a 32-bit > float. > > The next of the optimizations concern checking whether the comparison > against CST is unambiguous allowing it to be replaced with a integer > comparison. For reference, consider the table below which shows the > default conversion of integers to IEEE 32-bit float. > > (float)16777211 => 16777211.0f; > (float)16777212 => 16777212.0f; > (float)16777213 => 16777213.0f; > (float)16777214 => 16777214.0f; > (float)16777215 => 16777215.0f; > (float)16777216 => 16777216.0f; > (float)16777217 => 16777216.0f; // rounded > (float)16777218 => 16777218.0f; > (float)16777219 => 16777220.0f; // rounded > (float)16777220 => 16777220.0f; > (float)16777221 => 16777220.0f; // rounded > (float)16777222 => 16777222.0f; > (float)16777223 => 16777224.0f; // rounded > (float)16777224 => 16777224.0f; > (float)16777225 => 16777224.0f; // rounded > (float)16777226 => 16777226.0f; > > Observe that it's safe to optimize (float)i == 16777212.0f to the > equivalent i == 16777212 (as this is the only integer that can > convert to that floating point constant), but that it's unsafe to > optimize (float)i == 16777220.0f, as with default rounding there > are three possible integer values that FLOAT_EXPR to 16777220.0f. > The pragmatic check used in this patch is to confirm that (float)(i-1) > and (float)(i+1) are both distinct from (float)i before simplifying > the comparison to an integer-typed comparison. > > Finally, this patch also handles non-default rounding modes. > In the table above, it's safe to optimize (float)i == 16777222.0f > in IEEE's default rounding mode, but not in all FP rounding modes. > This eventuality is handled by testing whether the (float)i, the > (float)(i-1) and the (float)(i+1) are all exactly rounded when > -frounding-math is specified. > > This patch has been tested on x86_64-pc-linux-gnu with make bootstrap > and make -k check, both with and without --target_board=unix{-m32} > with no new failures. Ok for mainline? If the testcases need to be > tweaked for non-IEEE targets (the transformations themselves should > be portable to VAX and IBM floating point formats) hopefully that > can be done as follow-up patches by folks with the appropriate > effective-targets? > > > 2024-07-28 Roger Sayle > > gcc/ChangeLog > PR tree-optimization/57371 > * fold-const.cc (fold_cmp_float_cst_p): New helper function. > * fold-const.h (fold_cmp_float_cst_p): Prototype here. > * match.pd ((FTYPE) N CMP CST): Use ranger to determine > whether value is exactly representable by floating point type, > and check flag_trapping_math if not. Use the new helper > fold_cmp_float_cst_p to check that transformation to an integer > comparison is safe. > > gcc/testsuite/ChangeLog > PR tree-optimization/57371 > * c-c++-common/pr57371-6.c: New test case. > * c-c++-common/pr57371-7.c: Likewise. > * c-c++-common/pr57371-8.c: Likewise. > * c-c++-common/pr57371-9.c: Likewise. > * c-c++-common/pr57371-10.c: Likewise. Nice. I was a bit concerned about using Ranger in match.pd as match.pd can be used for GENERIC as well as GIMPLE. But it looks like you handled that reasonably. Similarly for the other FP formats. As you note, I wouldn't be terribly surprised if the other FP formats need testsuite adjustments. I'd hoped we had a target selector, but we don't. Does it make sense to use "add_options_for_ieee" to conditionally add the necessary target options in the tests? It only affects alpha, sh & rx, so it's unlikely to have been needed in your testing. Jeff