From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18920 invoked by alias); 1 Aug 2007 15:27:46 -0000 Received: (qmail 18900 invoked by uid 22791); 1 Aug 2007 15:27:44 -0000 X-Spam-Check-By: sourceware.org Received: from wa-out-1112.google.com (HELO wa-out-1112.google.com) (209.85.146.181) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 01 Aug 2007 15:27:37 +0000 Received: by wa-out-1112.google.com with SMTP id m16so223792waf for ; Wed, 01 Aug 2007 08:27:36 -0700 (PDT) Received: by 10.115.89.1 with SMTP id r1mr841606wal.1185982055598; Wed, 01 Aug 2007 08:27:35 -0700 (PDT) Received: by 10.115.91.12 with HTTP; Wed, 1 Aug 2007 08:27:35 -0700 (PDT) Message-ID: <4aca3dc20708010827k7ff7ba67kfa156d3428eed071@mail.gmail.com> Date: Wed, 01 Aug 2007 15:27:00 -0000 From: "Daniel Berlin" To: "Tehila Meyzels" Subject: Re: [RFC] Improve Tree-SSA if-conversion - convergence of efforts Cc: dpatel@gmail.com, gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org, "Michael Matz" , "Revital1 Eres" , trevor_smigiel@playstation.sony.com, "Ulrich Weigand" , "Victor Kaplansky" , "Ayal Zaks" , "Dorit Nuzman" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4aca3dc20707310800j41fb5cel4ef815bbad42be07@mail.gmail.com> Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2007-08/txt/msg00015.txt.bz2 On 8/1/07, Tehila Meyzels wrote: > "Daniel Berlin" wrote on 31/07/2007 18:00:57: > > > > > I agree with you for conditional stores/loads. > > Great! > > > > > The unconditional store/load stuff, however, is exactly what > > tree-ssa-sink was meant to do, and belongs there (this is #3 above). > > I'm certainly going to fight tooth and nail against trying to shoehorn > > unconditional store sinking into if-conv. > > Sometimes, store-sinking can cause performance degradations. > One reason for that, is increasing register pressure, due to extending life > range of registers. > > In addition, in case we have a store followed by a branch, store sinking > result will be a branch followed by a store. > On some architectures, the former can be executed in parallel, as opposed > to the latter. > Thus, in this case, it worth executing store-sinking only when it helps the > if-conversion to get rid of the branch. > > How do you suggest to solve this problem, in case store-sinking will be > part of the tree-sink pass? > Store sinking already *is* part of the tree-sink pass. It just only sinks a small number of stores. The solution to the problem that "sometimes you make things harder for the target" is to fix that in the backend. In this case, the scheduler will take care of it. All of our middle end optimizations will sometimes have bad effects unless the backend fixes it up. Trying to guess what is going to happen 55 passes down the line is a bad idea unless you happen to be a very good psychic. As a general rule of thumb, we are happy to make the backend as target specific and ask as many target questions as you like. The middle end, not so much. There are very few passes in the middle end that can/should/do ask anything about the target. Store sinking is not one of them, and I see no good reason it should be. > Another point, what about (unconditional) load hoisting: > It's surely not related to sink pass, right? > PRE already will hoist unconditional loads out of loops, and in places where it will eliminate redundancy. It could also hoist loads in non-redundancy situations, it is simply the case that it's current heuristic does not think this is a good idea. Thus, if you wanted to do unconditional load hoisting, the thing to do is to make a function like do_regular_insertion in tree-ssa-pre.c, and call it from insert_aux. We already have another heuristic for partially antic fully available expressions, see do_partial_partial_insertion