From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15250 invoked by alias); 22 Sep 2004 04:34:15 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 15239 invoked from network); 22 Sep 2004 04:34:13 -0000 Received: from unknown (HELO www.eyesopen.com) (208.41.78.163) by sourceware.org with SMTP; 22 Sep 2004 04:34:13 -0000 Received: from localhost (roger@localhost) by www.eyesopen.com (8.11.6/8.11.6) with ESMTP id i8M3kpT21090; Tue, 21 Sep 2004 21:46:51 -0600 Date: Wed, 22 Sep 2004 09:38:00 -0000 From: Roger Sayle To: Jeffrey A Law , Kaveh Ghazi , Eric Christopher cc: gcc@gcc.gnu.org Subject: Re: Difference between {expand,fold,simplify}_builtin_foo ??? In-Reply-To: <1095737658.10950.326.camel@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-09/txt/msg01263.txt.bz2 On Mon, 20 Sep 2004, Jeffrey A Law wrote: > > However what about fold_builtin_*? Both fold_builin_* and > > simplify_builtin_* return trees. Are the fold_ variants allowed to > > produce non-gimple? Or are fold_builtin_* and simplify_builtin_* > > really the same and we should canonicalize the naming convention? > I didn't realize we had a 3rd routine. Ugh. I don't know which is > preferred. Sigh. Hi Jeff and Kaveh, My understanding/intention is that fold_builtin_foo is the preferred tree folding interface, and it is allowed to generate non-gimple trees. All the uses of simplify_builtin and fold_builtin in the middle-end and tree-ssa have been converted to check whether their return values are in gimple form and either ignore the result, or thanks to Jakub's recent patch re-gimplify it. The APIs to both fold_builtin and simplify_builtin have been synchronized, such that as functionality is consolidated between the two fold_builtin will eventually be a replacement for simplify_builtin and all the simplify_builtin_foo forms can go away. Generally, there should not be a need to call fold_builtin_foo (or simplify_builtin_foo) from the RTL expanders such as expand_builtin_foo. The RTL expansion should be able to rely on the tree being fully folded prior to expansion, however, there may be some duplication of these optimizations when the expand_builtin_* functions checks whether RTL expansion has introduced an optimization opportunity, i.e. checking whether expand_expr has return const0_rtx, where the fold form may have checked for integer_zerop. This duplication dates back to the branch for tree-ssa where in the tree-ssa development tree the simplify_* forms of these functions were added to enable optimizations during tree-ssa's DOM and CCP passes, whilst on mainline the usual usual improvements/clean-ups in constant folding resulted in fold_builtin with near identical functionality. Originally on mainline fold was "destructive" and therefore unsuitable for tree-ssa, and tree-ssa at that time could only handle gimple trees. Once the branch/mainline were merged this became needless duplication and the effort of integrating the two schemes continued: See http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00312.html Anyway, I hope this explains where things currently stand, or my perspective of it. Eric Christopher's patch looks exactly right :> Roger --