This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: two-element struct performance (was: strict-aliasing and typedefs)
- From: law at redhat dot com
- To: Richard Henderson <rth at redhat dot com>
- Cc: 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 at gcc dot gnu dot org
- Date: Fri, 20 Feb 2004 08:02:00 -0700
- Subject: Re: two-element struct performance (was: strict-aliasing and typedefs)
- Reply-to: law at redhat dot com
In message <20040220080315.GA25175@redhat.com>, Richard Henderson writes:
>On Thu, Feb 19, 2004 at 04:16:59PM -0700, law@redhat.com wrote:
>> Doing better would require that the tree-ssa optimizers know about ABI
>> details for passing parameters and return values -- if it had that knowledg
>e
>> then it would know that the caller will provide a suitable memory location
>> for the return value and we could use it directly instead of first building
>> the return value in T.6.
>
>I don't know that tree-ssa knowledge of ABI details is quite necessary.
>
>I think if we'd performed the computation into a RESULT_DECL rather than
>into a VAR_DECL temporary, that would effectively do the job since we
>can arrange for the RESULT_DECL to have rtl appropriate for a caller
>provided memory location.
Yea, I came to to roughly the same conclusion after posting that message.
In fact, I _think_ that's precisely what the named return value optimization
is supposed to do for us. However, NRV optimizations happen too early
in the C++ front-end. Jason and I briefly discussed moving it to a later
point some time ago. I'll take a look at that once I've got the dominator
optimizer improvements installed (they're triggering some weirdness in
PRE).
jeff