This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Misc C++ improvements
- From: Jason Merrill <jason at redhat dot com>
- To: law at redhat dot com
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 20 Mar 2003 16:33:30 -0500
- Subject: Re: [tree-ssa] Misc C++ improvements
- References: <200303202120.h2KLKSNo001952@speedy.slc.redhat.com>
On Thu, 20 Mar 2003 14:20:28 -0700, law at redhat dot com wrote:
> Allowing this means minor changes elsewhere -- namely that we need to
> treat a RESULT_DECL in a manner similar to a VAR_DECL or PARM_DECL.
> The nice thing is for the cases where we got this stuff, allowing the
> RESULT_DECL to be used in this way results in nice efficient code
> (on-par with with the mainline compiler generates and much better than
> if we had forced the value through a temporary).
Sounds good. Is it safe to assume that we won't get into this sort of
situation when the function return value needs to be set up specially?
> 2. Apparently in C++ you can get a TYPE_DECL with a field which refers
> back to the TYPE_DECL (it happens in the testsuite somewhere).
I don't understand why we're walking into TYPE_DECLs at all. Shouldn't
that be RECORD_TYPE (et al) instead?
> This patch also tightens the test for rewriting the RHS of a MODIFY_EXPR
> appearing in a RETURN_EXPR so that the RHS is only rewritten if it is a
> CALL_EXPR.
Why? The main reason I wanted to allow a full rhs before was for
CALL_EXPRs. Is it useful for something else?
> Note that there's still some non-CFG issues we need to resolve to be able
> to use the tree-ssa optimizers with C++ -- for example the way named
> return value optimizations are implemented does not play well with DCE.
Yes, I think I chose the wrong implementation. Would it work better for us
to just do a search and replace of the chosen VAR_DECL with the
RESULT_DECL?
Jason