Re: GCC 4.3.0 Status Report (2007-06-07)

[Mark Mitchell <mark at codesourcery dot com>]

Michael Meissner wrote:

> I've looked at the changes, and I think with a minor bit of abstraction, we can
> modify the backends so that they don't care how the arguments are implemented.

Thanks for working on this!

> However, I think changing the representation of the arguments is a much more
> extensive process, and I don't think we should be doing it right now (there are
> around 220 references to TYPE_ARG_TYPES in the machine independant and front
> ends parts of the compiler).  But it would allow LTO to make these changes on
> their branch, and be able to slip in to use the backends without further
> change.

I think we want to avoid making the same mistake we did last time:
mixing these changes up with LTO.  They will help LTO (by reducing
memory use), but they're logically independent.  So, if we're not
comfortable putting the changes on the mainline, they should go on some
new branch.

I agree that introducing the abstractions first, and then switching the
implementation afterwards, is a good idea.  That's what Sandra did for
CALL_EXPRs and it worked well.  However:

> For the third case, it is fairly simple to switch the code to use
> num_parm_types and nth_parm_types.  This will mean a slight degradation in the
> code that handles arguments (for handling argument n, you need to do n-1
> pointer chases).

I don't think we can do this on mainline.  That's introducing
quadradicity, and someone will have a 100-argument function, and then
we'll be sad.  So, I think we need to do something different.  One
possibility is:

  FOR_EACH_ARG_TYPE(fn_type, arg_type)
    {
    }

which expands today to something like:

    for (arg_iter = TYPE_ARG_TYPES (fn_type),
         arg_type = arg_iter ? TREE_VALUE (arg_iter) : NULL_TREE;
         arg_iter;
         arg_iter = TREE_CHAIN (arg_iter),
         arg_type = arg_iter ? TREE_VALUE (arg_iter) : NULL_TREE)

and, later to something like:

  for (arg_indx = 0, arg_type = nth_parm_type (fn_type, arg_index);
       arg_indx != num_parm_types (fn_type);
       ++arg_indx)

Then, in both cases, the code can use arg_type in the body of the loop.

I think some of the abstractions, like stdarg_p and prototyped_p, are
unquestionably a good thing, and ought to go in forthwith.  That will
reduce the number of places TYPE_ARG_TYPES is used directly.  And, we
don't have to create a branch to do that part.  So, I'd suggest
preparing patches against mainline for those bits.  How does that sound?

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713