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: var_args for rs6000 backend


"Yao Qi qi" <qiyaobit@hotmail.com> writes:

> New data types were added into GCC as well as new modes.

It might help if you give a brief overview of what you are trying to
do (maybe you already have, and I forgot).  Also, I assume you are
working with mainline gcc.

> Argument
> passing and
> return value works well, but when I pass  arguments of these new types
> of variable length,
> and return a certain arguments in parameters list, the value is
> incorrect on PowerPC, but
> works well on x86.  So I think it has something to do with PowerPC backend.

Are you saying that you have new types which have variable length?
Those are certainly trickier to handle.  Standard C and C++ do not
pass any variable length types as arguments, so it's not surprising
that it will take some work.

PowerPC argument passing is significantly different from x86 argument
passing because on the x86 all arguments are passed on the stack
(modulo the -mregparm option which you are probably not using).  On
the PowerPC arguments are mostly passed in registers, overflowing to
the stack, and you need to worry about three different types of
registers: general registers, floating point registers, and vector
registers.

> Now, the most difficult thing for me is error location.  I do not
> which part of PowerPC backend caused this problem.  I dumped the test
> case in RTL form with option -dr and in assembly form, but both of
> them are not informative enough to expose the error.
> 
> This "bug" may be relative to argument passing, stack alloction, new
> modes and register allocation, but I do not know how to get enought
> information about these fields.  Could anybody give me some
> suggestions about information collection for them?

There aren't any particularly helpful debugging options here.  You
should know that this code often interacts with the function prologue
code, which is not inserted until the flow2 pass, so to see those
instructions in RTL you need -dw.

I often find it necessary to add debugging prints to these functions
to show where parameters are found in registers and/or on the stack,
and what kind of thing va_arg returns.  These prints most conveniently
take the form of
	  if (dump_file)
	    fprintf (dump_file, ...);
to appear in the relevant file dumped by -da.

Ian


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