From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18810 invoked by alias); 5 May 2008 01:16:02 -0000 Received: (qmail 18702 invoked by uid 48); 5 May 2008 01:15:14 -0000 Date: Mon, 05 May 2008 01:16:00 -0000 Message-ID: <20080505011514.18701.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug target/32871] [avr] Bad optimisation - gcc is pushing too many registers In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "hutchinsonandy at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-05/txt/msg00270.txt.bz2 ------- Comment #8 from hutchinsonandy at gcc dot gnu dot org 2008-05-05 01:15 ------- The following information from Kenny Zadeck, shows why the solution does not work. This limitation is not avoidable at the present time without causing compilation time/memory regressions on other targets. So we will have to live with the overly cautious saving of registers. > The target computes offset (INITIAL_ELIMINATION_OFFSET). This is called several times during register allocation (no doubt because something changes). Offset is a function of the number of registers saved. So I used DF_REG_DEF_CHAIN to work out precisely saved registers. But this information is out of date and so the offset is wrong. > However, info provided by df_regs_ever_live_p, is updated. > > So I think the live info is updated in global.c but not the chains. Is there a sane way around this or should I put this one on "too difficult list"? > > best regards > There are a three things to consider: 1) Incremental updating is turned off during global. This was perhaps a mistake, but what I did not want to get into was rescanning each insn that uses/defines a register whenever that register gets assigned. By turning off rescanning, each insn is only rescanned once, after all of its operands have had their registers assigned. 2) Turning this off is most likely the cause of your grief. It is possible that you could move the call to turn off scanning until later, after your bit of foolishness happens but before the actual registers are assigned, but the truth is that i really do not really understand the information flow within global/reload so i did not consider something like this. 3) Incremental scanning could be turned back on, but the cost is quite high because most insns have many operands and because reload can change the assignment of registers after global gets finished. Kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32871