From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 9B35F3858D1E for ; Sat, 15 Oct 2022 08:54:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9B35F3858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1665824041; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=j4DXhn9lt9DwDSDCKrcHrcxHLSTD2S0Q2nJLdajqFnE=; b=M3kpK/WrMN/A4bjVy2Cf7WBLSYOGuTVQghg5fbiJjJqORlQsMMPxlHr/HZPkX5w5QPKv2N lMLx+vGZDIHR7mev7ZJGSlcvCucOZlExx/Vue+Mi1JGpOkdEJbWXZL61/IP9IbsJ9m2Py7 XiCRSD2hNMnyS/QxA9vTwG0G0Py49+Q= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-214-LvptoLQ6Ok2ciLYSFlAaeQ-1; Sat, 15 Oct 2022 04:53:58 -0400 X-MC-Unique: LvptoLQ6Ok2ciLYSFlAaeQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id AAD563C11EBE; Sat, 15 Oct 2022 08:53:57 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.55]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 67C04C5C560; Sat, 15 Oct 2022 08:53:57 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 29F8rsuB286974 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sat, 15 Oct 2022 10:53:55 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 29F8rsT8286973; Sat, 15 Oct 2022 10:53:54 +0200 Date: Sat, 15 Oct 2022 10:53:53 +0200 From: Jakub Jelinek To: Martin Uecker Cc: "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH] middle-end IFN_ASSUME support [PR106654] Message-ID: Reply-To: Jakub Jelinek References: <4dcc975beb8b39ab4d57b28334c6ab3348855bd9.camel@gmail.com> <9697ad669628e472f7b5f7834a3982b190bb7e41.camel@gmail.com> MIME-Version: 1.0 In-Reply-To: <9697ad669628e472f7b5f7834a3982b190bb7e41.camel@gmail.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,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 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. 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. 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. 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. We don't warn for sizeof (i++) and similar either. __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. Jakub