This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [ast-optimizer-branch]: SAVE_EXPR's not simplified right
--On Tuesday, May 07, 2002 01:33:25 PM +0100 Jason Merrill
<jason@redhat.com> wrote:
>>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:
>
>> --On Monday, May 06, 2002 08:31:57 AM -0700 Zack Weinberg
>> <zack@codesourcery.com> wrote:
>
>>> Maybe it's time to get rid of SAVE_EXPR altogether? Per Bothner had a
>>> pretty detailed proposal for what to replace it with -- search the
>>> mailing lists for LET_EXPR.
>
>> That would be good. I'd go even further; just create explicitly create
>> temporaries in DECL_STMTs and use them. It's not hard to keep track
>> of the most recently opened scope so that you know where to put such
>> statements.
>
> Are you suggesting this at tree generation time, or as a post-processing
> pass? I would lean towards the latter. We could also do something
> similar for TARGET_EXPR.
In my perfect world, we'd build a C++ version of trees first. Such a
thing probably wouldn't have SAVE_EXPRs because it would only serve to
make explicit things that are implicit in the language: which overloaded
function are we calling, etc. But, for instance, "new" would still be
a NEW_EXPR, not a call to "operator new" followed by a constructor call.
So, no SAVE_EXPRs there.
Then, we'd convert that to more C-like trees (but with exception handling
constructrs). At that point, we'd avoid SAVE_EXPRs by generating the
right DECL_STMTs.
So, I'd just completely remove SAVE_EXPRs from tree.def completely.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com