Re: var_args for rs6000 backend

["Yao qi" <qiyaobit at hotmail dot com>]

> From: Ian Lance Taylor <ian@airs.com>
> To: "Yao Qi qi" <qiyaobit@hotmail.com>
> CC: gcc@gcc.gnu.org
> Subject: Re: var_args for rs6000 backend
> Date: 07 Sep 2005 09:14:49 -0700
>
> "Yao Qi qi" <qiyaobit@hotmail.com> writes:
>
>
> 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.
I am sorry for unclear discription in last mail and I will try to clarify it 
now.

I am working on GCC dfp branch for *only* one month.  Three new data types
are added into GCC for the consideration of precision.  These three new
data types works well in argument passing and value return, but can not
deal with variable argument passing with macros va_arg,va_start, and
va_end in stdarg.h well.  The value got from va_arg is always wrong on
PowerPC.
Do you think I am on a right way to describe a problem clearly in this 
community?
If not, feel free to tell me.
> 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
Yes, I have not tasted this option.  When I specify this option, there are
more failures than before, but this options has nothing to do with variable
argument passing.  That case can run well with and without this option
respectively.

> 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.
Yes, I have browsed the 64-bit PowerPC ELF ABI Supplement, and IMO,this
issue is only relative to floating point registers, because all the new data
types are new floating-point types.
> 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.
This optins is great! The rtl file I dumped out is more informative than
what I have done before with -dr and I can map it to assembly easily.

However, I am not sure about the following things in rtl file I dumped,
;; End of basic block 0, registers live:
1 [1] 3 [3] 31 [31] 33 [1] 34 [2] 35 [3] 36 [4] 37 [5] 38 [6] 39 [7]
40  [8] 67 [ap] 113 [sfp]

I have searched it in Charpter 10 RTL representation in GCC internals for
GCC 4.0, but I can not find anything to describe it.  I guess it is a 
description
of register usage.  1 means r1 ,31 means r31, 33 means f2, am I right?
> 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.

I found not all the target in gcc/gcc/config directory use this 
functionality and is there
any principle or guideline for location selection of dump_file in source 
code?  I can add it
in any locations I am interested in but how about it for the general purpose 
in
gcc/gcc/config/rs6000/rs6000.c ?

Thanks very much for your reply.
> Ian


Best Regards
----------------
Yao Qi
Bejing Institute of Technology

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/