Accessing called function attributes in FUNCTION_ARG macro

Accessing called function attributes in FUNCTION_ARG macro

[Weddington, Eric]

Hi All,

This may be a dumb question, but I'm having difficulty finding the answer to this.

I'm working on a back-end and I have a function being called for the FUNCTION_ARG macro, and in that function I need to find out the attributes of the called function as this will affect the calling convention. I've tried looking at many of the other ports to see if anyone else is doing anything similar but so far I haven't found any other port that does that.

Could someone could point me in the right direction to do this?

Thanks,
Eric Weddington

Re: Accessing called function attributes in FUNCTION_ARG macro

[Georg-Johann Lay]

Weddington, Eric schrieb:
> Hi All,
> 
> This may be a dumb question, but I'm having difficulty finding the answer to this.
> 
> I'm working on a back-end and I have a function being called for the FUNCTION_ARG macro, and in that function I need to find out the attributes of the called function as this will affect the calling convention. I've tried looking at many of the other ports to see if anyone else is doing anything similar but so far I haven't found any other port that does that.
> 
> Could someone could point me in the right direction to do this?

Hi Eric,

1) Scan for the attributes in INIT_CUMULATIVE_ARGS
    and set up some "call-cookie" that stores the
    information as part of CUMULATIVE_ARGS structure.
    To do this, scan the provided tree for the attribute:
       if (fntype && has_attribute_p (fntype)) cookie = ...
2) Update te cookie as needed in FUNCTION_ARG et al.
    resp. use it to generate the arguments' locations.
3) If FUNCTION_ARG et al. gets called with VOIDmode,
    return a CONST_INT representing the cookie.
    The CONST_INT will then appear as op2 resp op3
    in expander of call/sibcall resp call_value/sibcall_value
4) If insn output depends on the cookie, use it to print asm

The trouble is, that if FUNCTION_OK_FOR_SIBCALL depends on the
information gathered in CUMULATIVE_ARGS, calls.c doesn't pass
that information to the backend. This is important if a sibcall
must not be done depending on where callee's args are being passed.
sibcall patterns must not fail, so you had to hack around that.
Or more probably, I am just missing that part :-/

To look up the attribute, I am using code like

static bool has_attribute_p (tree func, const char *name)
{
     tree a;
     if (FUNCTION_DECL == TREE_CODE (func))
        func = TREE_TYPE (func);
     gcc_assert (TREE_CODE (func) == FUNCTION_TYPE);
     a = lookup_attribute (name, TYPE_ATTRIBUTES (func));

     return a != NULL_TREE;
}

Georg-Johann