This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Reorganize expansion of nested functions
> > On Sun, Feb 01, 2004 at 03:25:53AM +0100, Jan Hubicka wrote:
> > > + /* PARAM is function parameter referenced by nested function, prepare to
> > > + produce correct code in that case. */
> > > + void
> > > + notice_parameter_referenced_by_nested_function (tree param ATTRIBUTE_UNUSED)
> > > + {
> > > + #ifdef NEED_SEPARATE_AP
> > > + get_arg_pointer_save_area (cfun);
> > > + #endif
> > > + }
> >
> > Why is this needed? Indeed, I would expect basically all of this:
>
> It is needed to make it possible to access the argument by nested
> functions. There is corresponding code in function.c
>
> /* If reached via arg pointer, get the arg pointer value
> out of that function's stack frame.
>
> There are two cases: If a separate ap is needed, allocate a
> slot in the outer function for it and dereference it that way.
> This is correct even if the real ap is actually a pseudo.
> Otherwise, just adjust the offset from the frame pointer to
> compensate. */
>
> #ifdef NEED_SEPARATE_AP
> rtx addr;
>
> addr = get_arg_pointer_save_area (fp);
> addr = fix_lexical_addr (XEXP (addr, 0), var);
> addr = memory_address (Pmode, addr);
>
> base = gen_rtx_MEM (Pmode, addr);
> set_mem_alias_set (base, get_frame_alias_set ());
> base = copy_to_reg (base);
> #else
> displacement += (FIRST_PARM_OFFSET (context) - STARTING_FRAME_OFFSET);
> base = lookup_static_chain (var);
> #endif
To be more specific (now when I am not in hurry), the problems I am
fighting with is that during expansion of nested functions, the need for
trampolines/nonlocal goto receivers and arg_pointer_save_area is
discovered and since the outer function is expanded later, they can be
taken into account.
Because I now expand it before, i have to discover these facts in
advance so the later expansion of nested functions won't mess things up.
Honza
> >
> > > ! examine_nested_functions_1 (tree * tp, int *walk_subtrees, void *data)
> >
> > to be handled by rtl expansion of the parent function.
>
> It is done by rtl expansion of nested function that hooks it into parent
> function if I understand it right. But I can move the walk around into
> the expansion somewhere.
> >
> > > expand_function_end ();
> > > +
> > > + expand_nested_functions ();
> >
> > As far as I can see, moving expansion of nested functions here
> > from expand_used_vars is the only substantive change.
>
> Yes, the other stuff is needed to make it work :)
>
> Honza
> >
> >
> > r~