This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH Re: [ast-optimizer-branch]: Simplify STMT_EXPR's
- From: Jason Merrill <jason at redhat dot com>
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: Sebastian Pop <m1sp at csc dot liv dot ac dot uk>,Daniel Berlin <dberlin at dberlin dot org>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 19 Jun 2002 17:45:24 +0100
- Subject: Re: PATCH Re: [ast-optimizer-branch]: Simplify STMT_EXPR's
- References: <Pine.LNX.4.44.0205021030560.4533-100000@dberlin.org><20020502161835.A9384@linux18.lxfarm.csc.liv.ac.uk><1020354525.9564.6.camel@tornado><wvl1yb31v30.fsf_-_@prospero.cambridge.redhat.com><20020619134423.GA30053@tornado.toronto.redhat.com>
>>>>> "Diego" == Diego Novillo <dnovillo@redhat.com> writes:
> On Wed, 19 Jun 2002, Jason Merrill wrote:
>> In this patch I haven't tried to preserve source position information for
>> inlined functions, because we don't support wrapping _STMTs in
>> EXPR_WITH_FILE_LOCATION. One obvious direction would be to support that.
>> I don't see a good way to use FILE_STMT to handle this, as we aren't
>> tracking source position during simplification. On the other hand, perhaps
>> we should be.
> But we are, after a fashion. When creating new _STMT nodes we
> set their line number from the originating statement. Would that
> suffice?
No; inlined functions are treated as coming from their point of definition,
not the call site. Anyway, I'm working on this.
>>>>> "Daniel" == Daniel Berlin <dberlin@dberlin.org> writes:
> On Wednesday, June 19, 2002, at 05:22 AM, Jason Merrill wrote:
>> Daniel's earlier patch would find the last EXPR_STMT at arbitrary depth.
>> I don't see anything in the docs or existing practice to suggest that
>> the return value can be nested further under the initial block, so I only
>> look there.
> I originally did this as well, relying on what the docs said. But IIRC,
> simplification accidently can create cases where the return value is
> nested under the initial block, and we need to handle this properly.
>[...]
> In fact, if you look at your code below, you changed it so it simplifies
> the body *after* creating the modify expression for the return value.
Yes, it's simpler that way.
> I'm not sure this doesn't screw up exactly because of the above.
> Have you checked to make sure the return value stays at the same scope
> level after we simplify the body?
No need; after we've created the modify expression, it doesn't matter where
it is, because we're not dealing with a STMT_EXPR anymore.
> We should probably add an abort if the last statement before the closing
> scope of the statement expression is now a scope end, rather than an
> executable statement (IE you have a close scope followed by a close
> scope, rather than an executable statement followed by a close scope), if
> it returns a value.
Yep, will do.
Jason