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 [EMAIL PROTECTED] (650) 331-3385 x713