From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by sourceware.org (Postfix) with ESMTPS id CCCE93858404 for ; Thu, 13 Oct 2022 08:11:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CCCE93858404 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id A4C4121FB4; Thu, 13 Oct 2022 08:11:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1665648713; h=from:from:reply-to: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=DkKAG9vF6tKg5RRrJaa6tLFY7PVP9XZCJ9KKNpfFvXY=; b=Tk7YXV/2FoMTOfMUY+oKjcyxFP6BNzLasCt9elx+B0d4VAK8crIXLBAoWUX8tgDpwzL5VC inLH6XQ2Jpxz50rwafMKcNDQLW6lkQILws1bxTGnsie432j8tL8fzYwl6/WZIiPF9EgcTb 259bGFCvVLhqV6q3ljNRNd54tPyrw5c= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1665648713; h=from:from:reply-to: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=DkKAG9vF6tKg5RRrJaa6tLFY7PVP9XZCJ9KKNpfFvXY=; b=fdv6CaUia24vEeONhsugJqbf2itWQaXLnJbx97ZMUdw1UG6PMXnhhcUZMG9XmlZ7B/+KOO bJlfQkjtLKInI+Bg== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 8F08B2C141; Thu, 13 Oct 2022 08:11:53 +0000 (UTC) Date: Thu, 13 Oct 2022 08:11:53 +0000 (UTC) From: Richard Biener To: Andrew MacLeod cc: Jakub Jelinek , Jan Hubicka , Aldy Hernandez , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] middle-end IFN_ASSUME support [PR106654] In-Reply-To: <94879a41-16b5-6ec4-51ab-4d931b608147@redhat.com> Message-ID: References: <244e087a-8680-9c21-0774-c7b6621e2eda@redhat.com> <144534bb-c25e-5303-47e5-cf56beb98261@redhat.com> <94879a41-16b5-6ec4-51ab-4d931b608147@redhat.com> User-Agent: Alpine 2.22 (LSU 394 2020-01-19) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1609957120-1140071071-1665648713=:18337" X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,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: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1609957120-1140071071-1665648713=:18337 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Wed, 12 Oct 2022, Andrew MacLeod wrote: > > On 10/12/22 10:39, Jakub Jelinek wrote: > > On Wed, Oct 12, 2022 at 10:31:00AM -0400, Andrew MacLeod wrote: > >> I presume you are looking to get this working for this release, making the > >> priority high? :-) > > Yes. So that we can claim we actually support C++23 Portable Assumptions > > and OpenMP assume directive's hold clauses for something non-trivial so > > people won't be afraid to actually use it. > > Of course, first the posted patch needs to be reviewed and only once it gets > > in, the ranger/GORI part can follow. As the latter is only an optimization, > > it can be done incrementally. > > I will start poking at something to find ranges for parameters from the return > backwards. If the return were if (return_val) return return_val; you could use path-ranger with the parameter SSA default defs as "interesting". So you "only" need to somehow interpret the return statement as such and do path rangers compute_ranges () > > >> Intersection I believe...?  I think the value from the assume's should add > >> restrictions to the range.. > > Sure, sorry. > > > >> I figured as much, I was just wondering if there might be some way to > >> "simplify" certain things by processing it and turning each parameter query > >> into a smaller function returning the range we determined from the main > >> one...   but perhaps that is more complicated. > > We don't really know what the condition is, it can be pretty arbitrary > > expression (well, e.g. for C++ conditional expression, so say > > [[assume (var = foo ())]]; > > is not valid but > > [[assume ((var = foo ()))]]; > > is. And with GNU statement expressions it can do a lot of stuff and until > > we e.g. inline into it and optimize it a little, we don't really know what > > it will be like. > > > > > > 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? > > Andrew > > > -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg) ---1609957120-1140071071-1665648713=:18337--