Re: [tuples] gimple-low and assorted machinery

[Diego Novillo <dnovillo@google.com>]

On 8/8/07 2:12 PM, Aldy Hernandez wrote:

> 3. We have a version of call_expr_flags for tuples: gimple_call_flags.
>    Yes, it sucks to have duplicate functionality, but we need a tuples
>    version *and* a tree version.

This one's easy.  Just factor out the code in call_expr_flags that deals
with the extracted fndecl and have both gimple_call_flags and
call_expr_flags call that routine.

>    Diego, could you please update the design document?

Nobody is tying your hands.  The code is Right There on the wiki ;)

OK, I'll do it.

>    In the GIMPLE_CALL tuple, we store the result from
>    get_callee_fndecl() as Diego had suggested, but we also need (after
>    gimplification) to do things depending on whether we have a
>    FUNCTION_DECL or not.

So we test for gimple_call_fn() being a FUNCTION_DECL.  I don't see
where we rely on the function value being NULL. We can just ask for
TREE_CODE (gimple_call_fn (gs)) == FUNCTION_DECL, or even better, code
this condition in a predicate is_gimple_indirect_call (gs).

Regarding the GC problem, the easiest solution I can think of is to have
the GIMPLE bodies inside a VEC and then have a pointer map as an index
into that VEC.  The pointer map is really only useful to avoid linear
scanning in set_gimple_body() and gimple_body().

This solves the problem because we now have GC roots pointing at all the
 sequence bodies.  The lowering is also ICEing here and there in
compile.exp.  I'll commit the changes after I fix all the regressions.