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: [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


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