From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) by sourceware.org (Postfix) with ESMTPS id A21BC3858D1E for ; Sat, 15 Oct 2022 08:07:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A21BC3858D1E 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-x52c.google.com with SMTP id s30so9646536eds.1 for ; Sat, 15 Oct 2022 01:07:49 -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=1lgLxggcUBN725SCdR7Bjtly1jpLQVW2+UfPaAQhQtY=; b=YfIQjYXrhY7EGm3bqQsUQupCpGBuW73rQYL7m7KPoSjVwF9Dnp4hk8JL3kX8Oyxvyv /ofv2E7DPSelbNjycCBgUgX/QrldOzT62XdaDPJ9U+JnA28/xsXVMumWq00nXvsubsRU BumvuCrL5ctlCxY/GSphHqd03s6q3e9Vl4rEzcE0KEnmKDd8Oly/I4hkDhlZN6YFsn8I za5pbSJmRf8iRY2w1VhMpFZtpu6V5j0SocCVYWo2rz8TKIPAaFQORhShnkjFpzq7xYrD v1JHmfmkAtEdSkcCIlGI8Yuef+r+QYXAPvrR3U5L3ERw/ieChQAWV5vUKhgXPoXuDTQb i5fQ== 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=1lgLxggcUBN725SCdR7Bjtly1jpLQVW2+UfPaAQhQtY=; b=anxQeot+m571TuEPaJmKYIwbM/aM4kLxapMTppHZ4n3z5jr/a5VGdqSt031kxeSVnv 6CgV/OZaXMQAgZ8BTTMprM0Cn3cxCuPLcHTS9hvEoL5gG74ltqIXcNp0hrIiaSvzZpco IQz4YpzI1mjCuZvQJupK7yrena5/SA5wsJRwEfvg9EKOxSDZRGVqupcDf0f/SX7nlFXX MfecqxMrsu9QmuPDPrKqcSoiDSN3KHFx3rSHIoG309orY86TwTOpu8wNjDtOoFrqcpz8 J618VELcynjeEKbOpAdhiwD8U/FHz7rWDbF/GTAnq3TLIvXKu/vMf95IXbEY8MZwjouI rWpw== X-Gm-Message-State: ACrzQf1MBG1cMHBhDRTjBEVh/+xhA72/CrvUZkM3Q4mULodE84IlXHqt /S6NyWsJbzAZRYje1dOJHjk= X-Google-Smtp-Source: AMsMyM4bVFsEnzKo2sJjgthenVHrkDSxVjYdXOq7r8UTp34V9iN0DjIbjRUAwtMDMFL2FRHn9L8CZA== X-Received: by 2002:a05:6402:4150:b0:44a:ec16:def4 with SMTP id x16-20020a056402415000b0044aec16def4mr1413400eda.21.1665821268261; Sat, 15 Oct 2022 01:07:48 -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 u8-20020a17090657c800b0078c1e174e11sm2710080ejr.136.2022.10.15.01.07.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 15 Oct 2022 01:07:47 -0700 (PDT) Message-ID: <9697ad669628e472f7b5f7834a3982b190bb7e41.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: Sat, 15 Oct 2022 10:07:46 +0200 In-Reply-To: References: <4dcc975beb8b39ab4d57b28334c6ab3348855bd9.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 Freitag, den 14.10.2022, 23:20 +0200 schrieb Jakub Jelinek: > On Fri, Oct 14, 2022 at 10:43:16PM +0200, Martin Uecker wrote: > > Am Montag, den 10.10.2022, 10:54 +0200 schrieb Jakub Jelinek: > > > Hi! > > > > > > My earlier patches gimplify the simplest non-side-effects assumptions > > > into if (cond) ; else __builtin_unreachable (); and throw the rest > > > on the floor. > > > The following patch attempts to do something with the rest too. > > > > My recommendation would be to only process side-effect-free > > assumptions and warn about the rest (clang does this for > > __builtin_assume). I do not think this is worth the > > I think that is bad choice and makes it useless. I think [[assume(10 == i + 1)]] could be useful as it is nicer syntax than if (10 != i + 1) unreachable(); but [[assume(10 == i++)]] is confusing / untestable and therefor seems a bit dangerous. But we do not have to agree, I just stating my opinion here. I would personally then suggest to have an option for warning about side effects in assume. > > complexity and I am not so sure the semantics of a > > hypothetical evaluation are terribly well defined. > > I think the C++23 paper is quite clear. Yes, you can't verify it > in debug mode, but there are many other UBs that are hard to verify > through runtime instrumentation. And none are good. Some are very useful though (or even required in the context of C/C++). But I think there should be a very good reason for adding more. Personally, I do not see [[assume]] how side effects is useful enough to justify adding another kind of untestable UB. Especially also because it has somewhat vaguely defined semantics. I don't know any formalization the proposed semantics and the normative wording "the converted expression would evaluate to true" is probably good starting point for a PhD thesis. > And, OpenMP has a similar feature (though, in that case it is even > a stronger guarantee where something is guaranteed to hold across > a whole region rather than just on its entry. > > > That you can not verify this properly by turning it > > into traps in debug mode (as this would execute the > > side effects) also makes this a terrible feature IMHO. > > > > MSVC which this feature was based does not seem to make > > much to sense to me: https://godbolt.org/z/4Ebar3G9b > > So maybe their feature is different from what is in C++23, > or is badly implemented? The paper says as the first sentence in the abstract: "We propose a standard facility providing the semantics of existing compiler built-ins such as __builtin_assume (Clang) and __assume (MSVC, ICC)." But Clang does not support side effects and MSVC is broken. But yes, the paper then describes these extended semantics for expression with side effects. According to the author this was based on discussions with MSVC developers, but - to me - the fact that MSVC still implements something else which does not seem to make sense speaks against this feature. > I think with what we have in the works for GCC we'll be able to optimize > in > int f(int i) > { > [[assume(1 == i++)]]; > return (1 == i++); > } > > int g(int i) > { > [[assume(1 == ++i)]]; > return (1 == ++i); > } > > extern int i; > > int h(void) > { > [[assume(1 == ++i)]]; > return (1 == ++i); > } > > > int k(int i) > { > [[assume(42 == ++i)]]; > return i; > } > at least f/g to return 1; and k to return 41; > The h case might take a while to take advantage of. But why? Do we really want to encourage people to write such code? Martin