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]

Re: Mapping calls to declarations


on 14/8/01 9:12 am, James Montgomerie at jrmg@dcs.ed.ac.uk wrote:

> on 13/8/01 10:47 pm, Richard Henderson at rth@redhat.com wrote:
> 
>> On Mon, Aug 13, 2001 at 05:45:48PM +0100, James Montgomerie wrote: How can I
>> get the tree expression for the call from within the instruction pattern?
>> 
>> You can't.
>> 
>> You should be grabbing this information while compiling the call in the first
>> place (when the information is available), and saving it somewhere.  What
>> cookies to you need?  Number and type of arguments?
>> 
> 
> Yup.
> 

[Replying to myself...]

Following Richard's advice, I seem to have managed to solve my problem,
albeit using a solution built on a hairy assumption rather than the C
standard...

I've defined the CUMULATIVE_ARGS structrure to store the information I need
(the number and modes of arguments), and I'm filling it in (as is usual) in
FUNCTION_ARG_ADVANCE.  In FUNCTION_ARG, taking a leaf from the ARM port, I'm
checking if the mode is VOIDmode, and if it is, assuming that the value I
return will be used as the second operand of the call instruction (or the
third of call_value).  Assuming this, I'm then abusing the system by taking
a copy of my CUMULATIVE_ARGS structure (into newly ggc_alloced space), and
(here comes the dodgy bit) casting the pointer to the copy to an int and
returning it, via a GEN_INT.  I then extract this value in the call (or
call_value) pattern, cast it back to a CUMULATIVE_ARGS *, and read my data
back out.

This seems to work, but the casting from pointers to ints and back makes me
generally 'nervous'.  If there's another, less messy, solution, I'd still be
grateful if it was pointed out.

Also, my knowledge of the garbage collector is near to zero - is this a safe
way to allocate and use memory (i.e. my memory's not going to be
de-allocated before I use it)?

Jamie.



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