introduce EH_ELSE tree and gimplifier

Richard Biener richard.guenther@gmail.com
Mon Jul 1 11:12:00 GMT 2019


On Fri, Jun 28, 2019 at 5:21 AM Alexandre Oliva <oliva@adacore.com> wrote:
>
> On Jun 27, 2019, Richard Biener <richard.guenther@gmail.com> wrote:
>
> > On Thu, Jun 27, 2019 at 10:18 AM Alexandre Oliva <oliva@adacore.com> wrote:
>
> >> @@ -909,6 +909,13 @@ DEFTREECODE (TRY_CATCH_EXPR, "try_catch_expr", tcc_statement, 2)
> >> The second operand is a cleanup expression which is evaluated
> >> on any exit (normal, exception, or jump out) from this expression.  */
> >> DEFTREECODE (TRY_FINALLY_EXPR, "try_finally", tcc_statement, 2)
> >> +
> >> +/* Evaluate either the normal or the exceptional cleanup.  This must
> >> +   only be present as the cleanup expression in a TRY_FINALLY_EXPR.
> >> +   If the TRY_FINALLY_EXPR completes normally, the first operand of
> >> +   EH_ELSE is used as a cleanup, otherwise the second operand is
> >> +   used.  */
> >> +DEFTREECODE (EH_ELSE, "eh_else", tcc_statement, 2)
>
> > It's a bit weird that this is a tcc_statement as opposed to tcc_expression,
>
> Erhm...  What's weird about it?  It is not something that belongs in an
> arbitrary expr, it's a lot more like a top-level statement, like
> try_finally, having side effects but no useful value.

It's weird because it appears in a TRY_FINALLY statement operand.
But I guess the line between statements and expressions in GENERIC
is muddy...

> > also I'd have called it EH_ELSE_EXPR for clarity.
>
> Now *that* would be weird IMHO.  No offense intended, but I'd have
> dropped the _EXPR from TRY_FINALLY_EXPR to make it match the
> "try_finally" string.

OK, let me say for consistency then ...

> What reasons are there for them to deserve the _EXPR suffix?

History I guess?  All 'old' tcc_statement are _EXPR.

> If I rename it to EH_ELSE_EXPR, should GIMPLE_EH_ELSE also get a _EXPR
> suffix?
>
>
> > I also wonder why TRY_FINALLY_EXPR didn't just get a third optional
> > operand?
>
> I considered that possibility, but I didn't expect EH_ELSE to be used
> often enough to bloat every TRY_FINALLY_EXPR with another operand, plus
> a flag or some other means to remove ambiguity between same-cleanup and
> no-else-cleanup.

Fair enough.

Richard.

>
> --
> Alexandre Oliva, freedom fighter  he/him   https://FSFLA.org/blogs/lxo
> Be the change, be Free!                 FSF Latin America board member
> GNU Toolchain Engineer                        Free Software Evangelist
> Hay que enGNUrecerse, pero sin perder la terGNUra jamás - Che GNUevara



More information about the Gcc-patches mailing list