This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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
michael.meissner@amd.com



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]