On Fri, Jun 08, 2007 at 01:27:39PM -0700, Mark Mitchell wrote: > Joseph S. Myers wrote: > > On Thu, 7 Jun 2007, Mark Mitchell wrote: > > > >> I am aware of three remaining projects which are or might be appropriate > >> for Stage 1: > > > > Do we at this point believe that the people who were working on updating > > the TYPE_ARG_TYPES changes (from the old LTO branch) for trunk are not now > > going to have them ready in time? > > I don't see any evidence that those changes will be ready. I haven't > heard of any progress from the volunteer at AMD who was working on that. > However, I also think that those changes could go in during Stage 2, if > they are ready by then.
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. 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. Just so people know what I'm talking about, the current function argument types are stored as a linked list, pointed to by TYPE_ARG_TYPES, using TREE_CHAIN nodes. The oldlto branch has changed this to a vector, and added some new functions: num_parm_types -- count the number of arguments nth_parm_types -- return nth argument (as a tree) nth_parm_types_ptr -- like nth_parm_types, but return & of tree alloc_parm_types -- allocate n parameters vec_heap2parm_types -- Make a parameter list stdarg_p -- Return true if arg has variable args The backends use the TYPE_ARG_TYPES field in 3 ways: 1) Determine whether the function is a stdarg function 2) Determine whether the function has a prototype 3) Other iteration over the arguments 4) Wants to know if we hit an incomplete type For the first case, I recomend implementing a stdarg_p function in tree.c and change all callers to use it. For the second case, no changes need to be done, since it just tests if TYPE_ARG_TYPES has been allocated. 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 suspect this is not performance critical code, but if it is, it would be simple to have a macro that does the iteration (ie, for the linked list case, it would do a TREE_CHAIN, and for the LTO case it would increment the counter and use nth_parm_types). I'm not sure what we want to do about case #4. Probably the best way is to provide a macro in the machine idependant portion of the compiler and use it. The backends that are affected are: arm: Has a simple loop to go through the arguments. avr: Wants to know if a function is a variable argument function. c4x: Wants to know if a function is prototyped, and has a simple loop that goes through the arguments. crx: Wants to know if a function is a variable argument function. i386: Wants to know if a function is a variable argument function. Also, the netware, winnt subports wants to know if we have an incomplete type. There is a simple loop. ia64: Wants to know if the function is prototyped. iq2000: Wants to know if a function is a variable argument function. m68k: Wants to know if a function is a variable argument function. mips: Wants to know if the function is prototyped and wants to know if a function is a variable argument function. mn10300: Wants to know if a function is a variable argument function. pa: Wants to know if the function is prototyped and wants to know if a function is a variable argument function. It could also use num_parm_type. som: Wants to know if a function is a variable argument function. rs6000: Wants to know if the function is prototyped and wants to know if a function is a variable argument function. It also has a simple loop to check the arguments that could use nth_parm_type. sh: Wants to know if the function is prototyped. sparc: Wants to know if the function is prototyped. spu-c: Has a simple loop to access the arguments. -- Michael Meissner, AMD 90 Central Street, MS 83-29, Boxborough, MA, 01719, USA [EMAIL PROTECTED]