From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26102 invoked by alias); 9 May 2003 22:51:59 -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 26049 invoked from network); 9 May 2003 22:51:59 -0000 Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sources.redhat.com with SMTP; 9 May 2003 22:51:59 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA20158; Fri, 9 May 03 18:56:40 EDT Date: Fri, 09 May 2003 22:51:00 -0000 From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10305092256.AA20158@vlsi1.ultra.nyu.edu> To: jh@suse.cz Subject: Re: An issue for the SC: horrible documentation quality of GCC Cc: gcc@gcc.gnu.org X-SW-Source: 2003-05/txt/msg00967.txt.bz2 For each use of the register (reg c) you look for the chain of operations preceeding it like: (set (reg b) (reg a) (set (reg c) (reg b) and you replace the use by the oldest copy of the value (reg a) in this case. Why? That seems, at best, to accomplish nothing and, at worst, to pessimize the code. I'm not familiar with the new register allocator, but in the original one, all of those registers, assuming they are local, will be tied together and all allocated the same hard register. It would seem to me that when you do this optimization, you run the real risk of increasing the lifetime of a register over what it was before, especially if you consider the cases where some of the registers in question are hard regs and some are global. Don't we already have code that knows how to handle these cases efficiently? I see, you are looking for something like (set (reg a) (reg b)) where reg b is known to be 100. Constant propagation will turn this into (set (reg a) (reg 100)) but it is possible that copy propagation would eeliminate the need for reg a entirely replacing all the uses by reg b (or this can be done in register allocation). I'm talking about register allocation, not copy propagation. In the compiler books this does not matter; A *lot* of things "don't matter" in compiler books: that's why they are *books*. ;-) It is not perfect, as in the case user already wrote code initializing variable to 100 many times, we won't cache the copy of 100 in a register. But if the constant of 100 can fit into one insn, why would you *want to* cache it in a register? It's more efficient to use it each time rather than waste a register. This is also interesting. How well does the heuristic work? In fact I would expect that it will often fail to elliminate the else block and result in moving NOP to the less frequently executed place in the superblock. I'm not sure what you mean here.