Re: var_args for rs6000 backend

[Ian Lance Taylor <ian at airs dot com>]

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

> 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.

I don't know where the DFP arguments are passed.  If they are passed
in the floating point registers, then is the fix as simple as handling
the new modes like SFmode and DFmode in rs6000_gimplify_va_arg?

> >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?

Yes.  The strings in square brackets are the name of the registers.
This is unfortunately unhelpful for the PowerPC, where the register
names are just numbers.  You can try using -mregnames to get better
strings.  Or just look at alt_reg_names in rs6000.c for a more useful
mapping from register number to register name.

> >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 ?

dump_file is a global variable.  It will be set if debugging is
enabled for whatever pass is executing at the moment.  Using -da turns
on debugging for all RTL passes.

Ian