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-elementstruct performance (was: strict-aliasing and typedefs) ]
- From: Diego Novillo <dnovillo at redhat dot com>
- To: Jeff Law <law 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 15:01:18 -0500
- Subject: Re: [tree-ssa] Generic NRV optimization [was Re: two-elementstruct performance (was: strict-aliasing and typedefs) ]
- Organization: Red Hat Canada
- References: <200402261939.i1QJdIr8015929@speedy.slc.redhat.com>
On Thu, 2004-02-26 at 14:39, law@redhat.com wrote:
> In message <1077813404.16194.423.camel@localhost.localdomain>, Diego Novillo wr
> >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.
>
The former is what I was hinting at with the idea of moving the RTL
expanding logic from expand_return(). It would have to be adapted, of
course.
The latter is going to prevent NRV on any target that builds a PARALLEL
or a REG RETURN_DECL, wouldn't it?
Diego.