From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21427 invoked by alias); 28 May 2009 10:07:29 -0000 Received: (qmail 21419 invoked by uid 22791); 28 May 2009 10:07:28 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 28 May 2009 10:07:22 +0000 X-RZG-AUTH: :LXoWVUeid/7A29J/hMvvT2k715jHQaJercGOZEmTjTVav7/dnIJ5weE= X-RZG-CLASS-ID: mo00 Received: from [192.168.0.34] (hightec-gate.internett.de [82.192.203.42]) by post.strato.de (mrclete mo48) (RZmta 18.37) with ESMTP id R02370l4S9vPnt ; Thu, 28 May 2009 12:07:19 +0200 (MEST) Message-ID: <4A1E700C.9070908@gjlay.de> Date: Thu, 28 May 2009 18:11:00 -0000 From: Georg-Johann Lay User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Weddington, Eric" CC: gcc@gcc.gnu.org Subject: Re: Accessing called function attributes in FUNCTION_ARG macro References: <258DDD1F44B6ED4AAFD4370847CF58D5069D9D0B@csomb01.corp.atmel.com> In-Reply-To: <258DDD1F44B6ED4AAFD4370847CF58D5069D9D0B@csomb01.corp.atmel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-05/txt/msg00657.txt.bz2 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