From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) by sourceware.org (Postfix) with ESMTPS id 3F28C3858C83 for ; Mon, 17 Oct 2022 05:52:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3F28C3858C83 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x532.google.com with SMTP id u21so14464999edi.9 for ; Sun, 16 Oct 2022 22:52:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=67aoLbhTJ1CGkLR77svyusSeRWty069Amo1MO4Wuq+g=; b=VD8w34tu5eLFbcr0MZx2Yuf9p722U24LFA+oax0TyPOmElU8ZDb9OFIG+AIn+2gDO5 jtpdsKuALM6Zr0C7cszJZjMEqh4Y0TRVu6l1fctSQMgy2yvauPLTB14hII6Z3j2ddQo7 sw6XV4V5F8UeBvnHO/6X93JM90CEabb+WiGCMUfwtE4/OekSH6OKm/bJW3XduR8QsxTm 2X6ktlf3D3BgfUNFqhtYb5WR/ORBt4NnoMO9rP4mUdTiVy+c0+QpqMwrkNdzaj3bk69q A1HQvruOSb9rlykmO1JqtyL7zj8noocdQnoIk161QQISiE8r6UGUdeKGOMjycb9F3iUd Q3YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=67aoLbhTJ1CGkLR77svyusSeRWty069Amo1MO4Wuq+g=; b=Tn1EtbowvAGhRF22Vvpyq3ck6mzuOFOmK7fi2mvoJp99tU2Fuk5ky1OcL1q+wRDM86 Mr7gdSn4LKKNLXFrM4rAahLNLDLt1vgGeGwA3y8JZTarHy/7NFhJsCZr0HlFgpLXZVKx /X7ZUYomzde32mZNGZ5A+JWaoyFiDw1W5j1Bei8jAzQitvJEWEfDC5VHHHghivvGFLMI 9y4s3plBi7Uj3nbQO0CXg63Jmpt78MA2hRlLHzniJXVXsOFYXvDNgeI6PzuKH9T6sbG1 1zbN6Le8MPM0/mEm8VqFm3prR0mylPWJVW/k5y1rwUTdh6LA8scXyTeaLsSy6ginhNHa iT9g== X-Gm-Message-State: ACrzQf0J9pWlprDhLJUTPSHuBE05elbMyCznqycndhM5uuPvuMrMcQEj wk7/QCHF7mwPOTNMTGkL6NQ= X-Google-Smtp-Source: AMsMyM7JqQ7vAiAewcSkhqMJgVZQFHY8WPXmgunEfgpgPinmy6orBvM2DG8plXamg9FhawKC6hbP5g== X-Received: by 2002:aa7:d7c5:0:b0:459:fad8:fd2 with SMTP id e5-20020aa7d7c5000000b00459fad80fd2mr8924681eds.336.1665985954836; Sun, 16 Oct 2022 22:52:34 -0700 (PDT) Received: from 2a02-8388-e203-9700-a1ba-94bc-d9c8-a446.cable.dynamic.v6.surfer.at (2a02-8388-e203-9700-a1ba-94bc-d9c8-a446.cable.dynamic.v6.surfer.at. [2a02:8388:e203:9700:a1ba:94bc:d9c8:a446]) by smtp.gmail.com with ESMTPSA id fg4-20020a056402548400b0045bef7cf489sm6544139edb.89.2022.10.16.22.52.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 16 Oct 2022 22:52:34 -0700 (PDT) Message-ID: <205ad2ba802a55e5e841979903b5ba4a3d6358b8.camel@gmail.com> Subject: Re: [PATCH] middle-end IFN_ASSUME support [PR106654] From: Martin Uecker To: Jakub Jelinek Cc: "gcc-patches@gcc.gnu.org" Date: Mon, 17 Oct 2022 07:52:32 +0200 In-Reply-To: References: <4dcc975beb8b39ab4d57b28334c6ab3348855bd9.camel@gmail.com> <9697ad669628e472f7b5f7834a3982b190bb7e41.camel@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.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: Am Samstag, den 15.10.2022, 10:53 +0200 schrieb Jakub Jelinek: > On Sat, Oct 15, 2022 at 10:07:46AM +0200, Martin Uecker wrote: > > But why? Do we really want to encourage people to > > write such code? > > Of course these ++ cases inside of expressions are just obfuscation. > But the point is to support using predicates that can be inlined and > simplified into something really simple the optimizers can understand. This makes sense,. > The paper shows as useful e.g. being able to assert something is finite: > [[assume (std::isfinite (x)]]; > and with the recent changes on the GCC side it is now or shortly will be > possible to take advantage of such predicates. > It is true that > [[assume (__builtin_isfinite (x)]]; > could work if we check TREE_SIDE_EFFECTS on the GCC side because > it is a const function, but that is a GNU extension, so the standard > can't count with that. std::isfinite isn't even marked const in libstdc++ > and one can figure that out during IPA propagation only. Hm, that already seems to work with if (!std::isfinite(x)) __builtin_unreachable(); https://godbolt.org/z/hj3WrEhjb > There are many similar predicates, or user could have some that are useful > to his program. And either in the end it wouldn't have side-effects > but the compiler doesn't know, or would but those side-effects would be > unimportant to the optimizations the compiler can derive from those. I still have the feeling that relying on something such as the pure and const attributes might then be a better approach for this. >From the standards point of view, this is OK as GCC can just set its own rules as long as it is a subset of what the standard allows. > As the spec defines it well what happens with the side-effects and it > is an attribute, not a function and the languages have non-evaluated > contexts in other places, I don't see where a user confusion could come. The user confusion might come when somebody writes something such as [[assume(1 == ++i)]] and I expect that people will start doing this once this works. But I am also a a bit worried about the slipperly slope of exploiting this more because what "would evaluate to true" implies in case of I/O, atomic accesses, volatile accesses etc. does not seem clear to me. But maybe I am worrying too much. > We don't warn for sizeof (i++) and similar either. Which is also confusing and clang does indeed warn about it outside of macros and I think GCC should too. > __builtin_assume (i++) is a bad choice because it looks like a function > call (after all, the compilers have many similar builtins) and its argument > looks like normal argument to the function, so it is certainly unexpected > that the side-effects aren't evaluated. I agree. Best Martin