GCC trunk SPEC2000 performance

[Toon Moene]

law@redhat.com wrote:

> The other possibility raised by David is that some phase of RTL generation
> can turn a REG into a MEM (perhaps ADDRESSOF elimination?)

Yep, he pointed it out to me because I missed it (too many mails coming
in asynchronously).

> Looking at function.c I see three lines which look like:
> 
>   PUT_CODE (reg, MEM);

Starting program: /usr/snp/lib/gcc-lib/i686-pc-linux-gnu/3.2/f771 apsi.f
-quiet -dumpbase apsi.f -O3 -version -o /tmp/ccilb8M2.s
GNU F77 version 3.2 20020618 (experimental) (i686-pc-linux-gnu)
        compiled by GNU C version 3.2 20020618 (experimental).

Breakpoint 1, gen_mem_addressof (reg=0x4010dd60, decl=0x40122230) at
../../combined/gcc/function.c:2917
2917      PUT_CODE (reg, MEM);
(gdb) p *reg
$1 = {code = REG, mode = SImode, jump = 0, call = 0, unchanging = 0,
volatil = 1, in_struct = 0, used = 0, integrated = 0, 
  frame_related = 0, fld = {{rtwint = 60, rtint = 60, rtuint = 60, rtstr
= 0x3c <Address 0x3c out of bounds>, rtx = 0x3c, 
      rtvec = 0x3c, rttype = 60, rt_addr_diff_vec_flags = {min_align =
60, base_after_vec = 0, min_after_vec = 0, 
        max_after_vec = 0, min_after_base = 0, max_after_base = 0,
offset_unsigned = 0, scale = 0}, rt_cselib = 0x3c, 
      rtbit = 0x3c, rttree = 0x3c, bb = 0x3c, rtmem = 0x3c}}}
(gdb) step
2918      MEM_ATTRS (reg) = 0;
(gdb) step
2919      XEXP (reg, 0) = r;
(gdb) p *reg
$2 = {code = MEM, mode = SImode, jump = 0, call = 0, unchanging = 0,
volatil = 1, in_struct = 0, used = 0, integrated = 0, 
  frame_related = 0, fld = {{rtwint = 60, rtint = 60, rtuint = 60, rtstr
= 0x3c <Address 0x3c out of bounds>, rtx = 0x3c, 
      rtvec = 0x3c, rttype = 60, rt_addr_diff_vec_flags = {min_align =
60, base_after_vec = 0, min_after_vec = 0, 
        max_after_vec = 0, min_after_base = 0, max_after_base = 0,
offset_unsigned = 0, scale = 0}, rt_cselib = 0x3c, 
      rtbit = 0x3c, rttree = 0x3c, bb = 0x3c, rtmem = 0x3c}}}

So, OK - that's it.  Addressof makes a MEM out of this register, so we
should accept it down the road.

Sorry for the mis-diagnose.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)