This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] Misc C++ improvements


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]