This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Generic NRV optimization [was Re: two-element struct performance (was: strict-aliasing and typedefs) ]
- From: law at redhat dot com
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: Andreas Schwab <schwab at suse dot de>, Joe Buck <jbuck at synopsys dot com>, Gabriel Dos Reis <gdr at integrable-solutions dot net>, Brad Lucier <lucier at math dot purdue dot edu>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 26 Feb 2004 12:39:18 -0700
- Subject: Re: [tree-ssa] Generic NRV optimization [was Re: two-element struct performance (was: strict-aliasing and typedefs) ]
- Reply-to: law at redhat dot com
In message <1077813404.16194.423.camel@localhost.localdomain>, Diego Novillo wr
ites:
>On Wed, 2004-02-25 at 09:07, Diego Novillo wrote:
>
>> #1 0x00000000005d0589 in change_address_1 (memref=0x2a9779fb30, mode=SImod
>e,
>> addr=0x2a97db3720, validate=1)
>> at /home/cygnus/dnovillo/perf/sbox/tree-ssa-branch/local.x86_64/src/gcc
>/emit-rtl.c:1770
>> 1770 abort ();
>> (gdb) list 1770
>> 1765 change_address_1 (rtx memref, enum machine_mode mode, rtx addr, int
> validate)
>> 1766 {
>> 1767 rtx new;
>> 1768
>> 1769 if (GET_CODE (memref) != MEM)
>> 1770 abort ();
>> 1771 if (mode == VOIDmode)
>> 1772 mode = GET_MODE (memref);
>> 1773 if (addr == 0)
>> 1774 addr = XEXP (memref, 0);
>> (gdb) p memref
>> $1 = 0x2a9779fb30
>> (gdb) pr
>> (parallel:BLK [
>> (expr_list (reg:SI 58 [ val ])
>> (const_int 0 [0x0]))
>> (expr_list (reg:DI 59 [ val+8 ])
>> (const_int 8 [0x8]))
>> ])
>>
>Well, we could move the RTL expanding logic from expand_return() but I'm
>not sure this the real fix. This will fail on every host that has a
>parallel:BLK in DECL_RTL of RESULT_DECL.
It's not the right fix.
We either need to make the expanders a lot smarter about expanding
references to part of a RESULT_DECL, particularly those which are
PARALLELs or REGs, or we need to not perform NRV on a function that
is going to return its value in a PARALLEL or REG.
The former is probably best long term, the latter is quite easy to
implement today and that's what I'm testing now.
jeff