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

["Michael Meissner" <michael dot meissner at amd dot com>]

On Tue, Jun 19, 2007 at 08:47:36PM -0700, Mark Mitchell wrote:
> 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.

See below.

> 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)
>     {
>     }

Yep, though I suspect in practice that the backends is not in performance
critical code.  I think we can replace most of the front/back end usages with
an iterator function.  The front ends need the ability to create/modify the
arguments, while the back ends only need to get the next argument.

I think a gradual approach is the right way.  I think this can be done in the
stage 2 time frame, but it could be pushed to gcc 4.4 (but we will have the
same problem as we have now).  The way I see it, the steps would be:

1) Add the basic infrastructure, iterator macros, stdarg_p, prototype_p,
   etc. to the tree.

2) Change the back ends, 1 by 1 to use the new infrastructure support.

3) Change the front ends, 1 by 1 to use the new infrastructure support.

4) Remove/rename TYPE_ARG_TYPES, and fix any random breakage.

5) Switch the infrastructure underneath to use vectors.

Until #4, you are only changing one thing at a time, and can easily verify that
the change works.

-- 
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
michael.meissner@amd.com