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 8F10B382E280 for ; Thu, 13 Oct 2022 09:57:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8F10B382E280 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=1665655078; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Th1F1SA+wl1DBkD18j46cCb2nGc8eZLJGL/6r5aEhLM=; b=XpSuYJ6mHAzooeXn3N+Ghw+LXECSGjJoLxO8RYxM39p6b4U6R+2R3+nwIhDXJKolbXDLmV mAd33OTImbitVkvZfD/159ygqMpwMLXUZSWAHMkpxgUhmTiugvdDtC4aaOsKCHjdZap1N2 gnB+EjVLOR1W3G7+J3clwbK3aCM0O0E= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-74-5qQlqr1qNAyNcue44vvd4A-1; Thu, 13 Oct 2022 05:57:54 -0400 X-MC-Unique: 5qQlqr1qNAyNcue44vvd4A-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id CDE898582B9; Thu, 13 Oct 2022 09:57:53 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.55]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8A2F7112131B; Thu, 13 Oct 2022 09:57:53 +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 29D9vejf2964680 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 13 Oct 2022 11:57:51 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 29D9vFrk2964679; Thu, 13 Oct 2022 11:57:15 +0200 Date: Thu, 13 Oct 2022 11:57:14 +0200 From: Jakub Jelinek To: Andrew MacLeod Cc: Richard Biener , Jan Hubicka , Aldy Hernandez , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] middle-end IFN_ASSUME support [PR106654] Message-ID: Reply-To: Jakub Jelinek References: <244e087a-8680-9c21-0774-c7b6621e2eda@redhat.com> <144534bb-c25e-5303-47e5-cf56beb98261@redhat.com> <94879a41-16b5-6ec4-51ab-4d931b608147@redhat.com> MIME-Version: 1.0 In-Reply-To: <94879a41-16b5-6ec4-51ab-4d931b608147@redhat.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=WINDOWS-1252 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.6 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 Wed, Oct 12, 2022 at 12:12:38PM -0400, Andrew MacLeod wrote: > No, I just meant that once we finally process the complicated function, and > decide the final range we are storing is for x_1 is say [20,30], we could > replace the assume call site with something like > >   int assume03_x (x) { if (x>= 20 || x <= 30) return x; gcc_unreachable(); } > > then at call sites: > >    x_5 = assume03_x(x_3); > > For that matter, once all the assume functions have been processed, we could > textually replace the assume call with an expression which represents the > determined range...  Kind of our own mini inlining?  Maybe thats even better > than adding any kind of support in fold_using_range..   just let things > naturally fall into place? > > .ASSUME_blah ( , , x_4); > > where if x is determined to be [20, 30][50,60] could be textually "expanded" > in the IL with > >   if (x<20 || x>60 || (x>30 && x < 50)) gcc_unreachcable(); > > for each of the parameters?   If we processed this like early inlining, we > could maybe expose the entire thing to optimization that way? That could work for integral parameters, but doesn't work for floating point nor when builtins are involved. We do not want to put floating point comparisons into the IL as __builtin_unreachable (); guards because they have observable side-effects (floating point exceptions/traps) and we wouldn't DCE them for those reasons. Similarly, if there are builtins involved we don't want to call the corresponding library functions because something wasn't DCEd. Jakub