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