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 [EMAIL PROTECTED]