introduce EH_ELSE tree and gimplifier
Alexandre Oliva
oliva@adacore.com
Fri Jun 28 03:21:00 GMT 2019
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.
> 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.
What reasons are there for them to deserve the _EXPR suffix?
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.
--
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