From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10301 invoked by alias); 1 Aug 2007 19:59:03 -0000 Received: (qmail 10292 invoked by uid 22791); 1 Aug 2007 19:59:02 -0000 X-Spam-Check-By: sourceware.org Received: from wa-out-1112.google.com (HELO wa-out-1112.google.com) (209.85.146.178) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 01 Aug 2007 19:58:56 +0000 Received: by wa-out-1112.google.com with SMTP id m16so290807waf for ; Wed, 01 Aug 2007 12:58:54 -0700 (PDT) Received: by 10.114.169.2 with SMTP id r2mr1066833wae.1185998334117; Wed, 01 Aug 2007 12:58:54 -0700 (PDT) Received: by 10.115.91.12 with HTTP; Wed, 1 Aug 2007 12:58:54 -0700 (PDT) Message-ID: <4aca3dc20708011258m60695665l31762ead15c9a9da@mail.gmail.com> Date: Wed, 01 Aug 2007 19:59:00 -0000 From: "Daniel Berlin" To: "Ayal Zaks" Subject: Re: [RFC] Improve Tree-SSA if-conversion - convergence of efforts Cc: "Dorit Nuzman" , dpatel@gmail.com, gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org, "Michael Matz" , "Revital1 Eres" , "Tehila Meyzels" , trevor_smigiel@playstation.sony.com, "Ulrich Weigand" , "Victor Kaplansky" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4aca3dc20708010827k7ff7ba67kfa156d3428eed071@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/msg00026.txt.bz2 On 8/1/07, Ayal Zaks wrote: > "Daniel Berlin" wrote on 01/08/2007 18:27:35: > > > 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. > > > > Hoisting a non-redundant load speculatively above an if may indeed be a bad > idea, unless that if gets converted as a result (and possibly even then > ...). Are we in agreement then that unconditional load/store motion for > the sake of redundancy elimination continues to belong to PRE/tree-sink, > and that conditional load/store motion for the sake of conditional-branch > elimination better be coordinated by if-cvt? > Yes. My only issue here is duplication of code that exists in other passes, not one of who/when/why things get done. IE it is easier to use PRE's infrastructure to do the unconditional load elimination, but still only do more than redundancy elimination when you will if-convert branches, then it would be to write a new pass. Your new pass would end up probably missing loads that PRE goes to trouble to get, and would duplicate a lot of the safety computation PRE already knows how to do. Of course, if you only see yourself moving 1 or two loads per function, it may be quicker to do just those in their own pass controlled by ifcvt. But if you are going to try to if-convert every branch, and every load inside those branches, you really don't want to try to make your computation as efficient as PRE makes it. A similar situation exists for unconditional store sinking/tree-ssa-sink.