This is the mail archive of the 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]

double gimplification in C++ FE

Hi Jason.  Hi folks.

I'm in the process of converting the C++ FE to tuples.  In doing so I
have noticed that the C++ FE will frequently gimplify bits of a tree,
and then expect gimplify_expr() to gimplify the rest.  This seems
redundant, as gimplify_expr() more often than not will gimplify the
entire tree structure, without regard to what parts the C++ FE already

For example, while gimplifying a TRY_BLOCK in C++, we do:

	genericize_try_block (tree *stmt_p)
	  tree body = TRY_STMTS (*stmt_p);
	  tree cleanup = TRY_HANDLERS (*stmt_p);

	  gimplify_stmt (&body);	<-------- BOO HISS
	  *stmt_p = build2 (TRY_CATCH_EXPR, void_type_node, body, cleanup);

Then, in gimplify.c:gimplify_expr():

        case TRY_FINALLY_EXPR:
        case TRY_CATCH_EXPR:
          gimplify_to_stmt_list (&TREE_OPERAND (*expr_p, 0));
          gimplify_to_stmt_list (&TREE_OPERAND (*expr_p, 1));
          ret = GS_ALL_DONE;

This behavior is common throughout C++.  The C++ FE calls gimplify_stmt
on bits of trees, but then gimplify_expr() has to gimplify again.

It seems to me that a better approach would be to pass the
tree structure as generic as we can (without calls to gimplify_stmt in
the C++ FE), and then let gimplify_expr do its job.

The reason I propose this is because with tuples, gimplify_expr()
accepts trees, not tuples.  So if we call gimplify_stmt in the C++ FE,
we end up with tuples which we cannot be passed to gimplify_expr.  So
it's better to leave things as generic trees, and let the gimplifier
proper do its magic.

Am I overlooking something?  Can I proceed with this approach?


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