Re: Expand from tuples

[Richard Guenther <richard dot guenther at gmail dot com>]

On Tue, Sep 1, 2009 at 3:46 AM, Michael Matz<matz@suse.de> wrote:
> Hi,
>
> this is the first part of expanding directly from tuples, instead of
> building temporary trees. ?It's doing the easy things, namely conditions,
> GIMPLE_GOTO, GIMPLE_LABEL, GIMPLE_NOP, GIMPLE_PREDICT, GIMPLE_RESX,
> GIMPLE_SWITCH, GIMPLE_ASSIGN and mostly GIMPLE_RETURN.
>
> It partly does GIMPLE_ASM, and leaves GIMPLE_CALL for later.
>
> Up to GIMPLE_RESX is trivial, for GIMPLE_SWITCH I changed expand_case
> slightly, also trivial.
>
> GIMPLE_ASSIGN is mostly trivial because when the LHS is not an SSA name or
> the RHS is a SINGLE_RHS I can simply use expand_assignment, which does
> everything correctly. ?If the LHS is an SSA name I can rely on the RHS
> being either UNARY_RHS or BINARY_RHS and hence use expand_expr_real_2
> directly. ?I can not rely on the expanded LHS being a simple pseudo or
> mem, though, in some cases it might be an promoted subreg, so that needs
> some compensation code I stole from expand_assignment (I know that it
> works on ppc). ?Ideally this promotion would already happen on tree-ssa
> side so that we could do away with promoted subregs, but well...
>
> GIMPLE_RETURN only mostly done because I sometimes have to build an
> explicit MODIFY_EXPR. ?Getting rid of that requires moving code around
> from expand_return to more generic RTL data movers. ?Something for later.
>
> GIMPLE_ASM only partly done because I was too lazy for this patch to get
> rid of using the three operand lists as tree lists, which requires some
> surgery on some callees of expand_asm_stmt too. ?It's otherwise straight
> forward. ?Luckily this rewiring doesn't require building new trees.
> Later.
>
> GIMPLE_CALL is a different beast. ?I have some patches doing parts of
> this, but they get a bit unwieldy, so for now I just fall back to build a
> CALL_EXPR and then use expand_assignment (or expand_expr_real_1). ?The
> patch includes some preparatory mechanic changes ala
> s/TREE_TYPE (exp)/rettype/ though. ?The call expander also doesn't
> need to fiddle itself with exception regions anymore (expand_gimple_stmt
> does this now in a central place).
>
> Amongst the problems for expanding calls are:
> * The LHS might be a handled_component(). ?expand_assignment has special
> ?code for that (using store_expr and store_field) that all need an
> ?unexpanded tree expression as RHS. ?Dealing with this will get a bit
> ?ugly, possibly duplicating code. ?OTOH this is a possibility to cleanup
> ?some code that is virtually unchanged since subversion history but
> ?contains some sequences that can't possibly be useful anymore.
> * sibcall target hook wants the full CALL_EXPR. ?Thankfully only three or
> ?four targets actually use that parameter (they mostly use only the
> ?function type), and those could do fine with a gimple stmt.
> * Interaction between builtins and call. ?The whole builtins.c is full of
> ?references to the tree (call) expression, calling back and forth between
> ?it, calls.c, targets and folders. ?It's a terrible maze, and will be
> ?noisy to change. ?Later.
>
> Now, even without the full thing we produce much fewer temporary trees
> than before (namely only for some returns and all calls).
>
> I've regstrapped this on x86_64-linux without regressions (all langs plus
> Ada).
>
> I've also bootstrapped and make-checked this on powerpc64-linux (all
> langs, no Ada, default-cpu=32), but didn't have a baseline for testsuite
> comparison. ?I'm building the latter right now.
>
> The only fragile thing in this patch is the second case of GIMPLE_ASSIGN
> (SSA name on lhs, unary/binary op on rhs), where some targets might have
> funny requirements (it's unbelievable how many routines we have for
> dealing with data movement on RTL, all doing slightly similar things with
> different pre- and post-conditions). ?If any they'll show up as ICEs in
> convert_move or expand_move or convert_modes or expand_expr_real_1 or
> store_expr or store_field or emit_move_insn or somewhere else with "move"
> in the name :-/
>
> In any case, assuming the ppc testsuite baseline doesn't reveal any
> regressions, okay for trunk?

The new expand_* helpers in cfgexpand.c need comments.

Ok with that fixed.

While this all looks like an ongoing (and eventually not finished for 4.5)
transition the benefit I would like to have for 4.5 is to get rid of the
tree annotation pointer that is currently in every tree.  Apart from the
use in expansion we only have the var annotation left where only
the SSA renaming and SSA coalescing has useful fields left.  At
least we should be able to make it a decl annotation instead of a
tree annotation.

Thanks,
Richard.