[Bug target/32871] [avr] Bad optimisation - gcc is pushing too many registers

["hutchinsonandy at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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