From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5822 invoked by alias); 2 Sep 2009 18:10:55 -0000 Received: (qmail 5811 invoked by uid 22791); 2 Sep 2009 18:10:54 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,SARE_RMML_Stock10,SPF_PASS X-Spam-Check-By: sourceware.org Received: from fg-out-1718.google.com (HELO fg-out-1718.google.com) (72.14.220.156) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 02 Sep 2009 18:10:44 +0000 Received: by fg-out-1718.google.com with SMTP id d23so439310fga.8 for ; Wed, 02 Sep 2009 11:10:38 -0700 (PDT) Received: by 10.86.226.32 with SMTP id y32mr2831133fgg.77.1251915038238; Wed, 02 Sep 2009 11:10:38 -0700 (PDT) Received: from localhost (79-67-69-193.dynamic.dsl.as9105.com [79.67.69.193]) by mx.google.com with ESMTPS id e20sm3896180fga.15.2009.09.02.11.10.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Sep 2009 11:10:37 -0700 (PDT) To: Adam Nemet Mail-Followup-To: Adam Nemet ,Richard Henderson , gcc@gcc.gnu.org, rdsandiford@googlemail.com Cc: Richard Henderson , gcc@gcc.gnu.org Subject: Re: Using MEM_EXPR inside a call expression References: <4A9D4A30.1040706@redhat.com> <19101.31379.70330.593500@ropi.home> <4A9D8815.2090103@redhat.com> <19101.38605.846896.513304@ropi.home> From: Richard Sandiford Date: Wed, 02 Sep 2009 18:10:00 -0000 In-Reply-To: <19101.38605.846896.513304@ropi.home> (Adam Nemet's message of "Tue\, 1 Sep 2009 14\:49\:01 -0700") Message-ID: <87zl9dz08a.fsf@firetop.home> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2009-09/txt/msg00051.txt.bz2 Adam Nemet writes: > Richard Henderson writes: >> On 09/01/2009 12:48 PM, Adam Nemet wrote: >> > I see. So I guess you're saying that there is little chance to optimize the >> > loop I had in my previous email ;(. >> >> Not at the rtl level. Gimple-level loop splitting should do it though. >> >> > Now suppose we split late, shouldn't we still assume that data-flow can change >> > later. IOW, wouldn't we be required to use the literal/lituse counting that >> > alpha does? >> >> If you split post-reload, data flow isn't going to change >> in any significant way. >> >> > If yes then I guess it's still better to use MEM_EXPR. MEM_EXPR also has the >> > benefit that it does not deem indirect calls as different when cross-jumping >> > compares the insns. I don't know how important this is though. >> >> It depends on how much benefit you get from the direct >> branch. On alpha it's quite a bit, so we work hard to >> make sure that we can get one, if at all possible. > > Thanks, RTH. > > RichardS, > > Can you comment on what RTH is suggesting? Besides cross-jumping I haven't > seen indirect PIC calls get optimized much, and it seems that splitting late > will avoid the data-flow complications. > > I can experiment with this but it would be nice to get some early buy-in. > > BTW, I have the R_MIPS_JALR patch ready for submission but if we don't need to > worry about data-flow changes then using MEM_EXPR is not necessary. I guess all three would work, but TBH, I think it's too dangerous to rely on dataflow not changing in an unwanted way. We'd also have to say specifically what that way is, and preferably assert for it somehow. Personally, I like the dataflow approach you said you'd taken originally. It's the kind of thing df was designed to make easy, and we already use df in md_reorg to implement -mr10k-cache-barrier. It should just be a case of making sure that all definitions have the same value. I suppose the danger of using MEM_EXPR is that (in the MIPS case) it isn't technically correct for functions that are initially directed at a lazy-binding stub. It probably wouldn't matter in practice though, since there'll be no lazy-binding stub if the address is ever used in a different way. I don't really have any objections to using MEM_EXPR. Richard