This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: function attributes
- From: Umesh Kalappa <umesh dot kalappa0 at gmail dot com>
- To: gnuuser dot raj at gmail dot com
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Wed, 16 Oct 2013 14:05:32 +0530
- Subject: Re: function attributes
- Authentication-results: sourceware.org; auth=none
- References: <CAKuVEhDgUgXCPSEL3gJ33d9tM8tPUhnUnYhOsCUK-NEOOhSKMQ at mail dot gmail dot com> <CAKOQZ8xwJ01S46_9A9ZZhJ+CMGhu9Nf7Q3ZibErZdf=goBSxvg at mail dot gmail dot com> <CAKuVEhDd0kaz8HGFsMeqZUm0iaw6O_-fe_0RwkrUQRkSYGPC4A at mail dot gmail dot com> <CAKOQZ8y2fs0jYzpNHd5C-2cc0MPGt6MT5aPCXfcY1YrvP_xTbg at mail dot gmail dot com> <CAKuVEhDc9kJPk-3V+mWk00GyZXK=Fr923xOXEAzR3U0vc3Tgkw at mail dot gmail dot com> <CAKOQZ8z+_kDqa=oJ59i+G+KmycpsnUc9c+jnc4z0eOjn2Lq9ww at mail dot gmail dot com>
You still stuck with this issue ???
~Umesh
On Tue, Oct 15, 2013 at 9:08 PM, Ian Lance Taylor <iant@google.com> wrote:
> On Tue, Oct 15, 2013 at 8:04 AM, Nagaraju Mekala <gnuuser.raj@gmail.com> wrote:
>> Hi Ian,
>>
>> Thanks for the reply.
>>
>> On Fri, Oct 11, 2013 at 10:31 PM, Ian Lance Taylor <iant@google.com> wrote:
>>> On Fri, Oct 11, 2013 at 9:20 AM, Nagaraju Mekala <gnuuser.raj@gmail.com> wrote:
>>>>
>>>> I observed that in rs6000 port longcall is implemented by using
>>>> CALL_LONG define.
>>>> #define CALL_LONG 0x00000008 /* always call indirect */
>>>> In the md file they are checking the operand with CALL_LONG
>>>> if (INTVAL (operands[3]) & CALL_LONG)
>>>> operands[1] = rs6000_longcall_ref (operands[1]);
>>>> In my port I dont have suchthing to compare. Can we somehow parse the
>>>> tree chain and check the attributes of the functions..
>>>
>>> Look at init_cumulative_args in rs6000.c to see how CALL_LONG is set
>>> based on the function attribute.
>>
>> I was able to get the function attribute from the init_cumulative_args
>> function. I have used the fndecl tree to get the attribute details
>> but I have failed to stop generating br instruction. It should print
>> bk instruction.
>> I was unable to relate the super attribute from init_cumulative_args
>> to the branch pattern in md file to generate bk instruction.
>> I have intialized a global variable to 1 if super is detected and
>> checking the same in my pattern.
>> My branch pattern looks like below
>> (define_insn "call_int1"
>> [(call (mem (match_operand:SI 0 "call_insn_simple_operand" "ri"))
>> (match_operand:SI 1 "" "i"))
>> (clobber (reg:SI R_RS))]
>> ""
>> {
>> register rtx t = operands[0];
>> register rtx t2 = gen_rtx_REG (Pmode,
>> GP_REG_FIRST + RETURN_ADDR_REGNUM);
>> if (GET_CODE (t) == SYMBOL_REF) {
>> if(super_var()) ---------------> Here I am
>> checking for global variable
>> {
>> return "bk\tr1,8\;%#";
>> }
>> else {
>> gen_rtx_CLOBBER (VOIDmode, t2);
>> return "br\tr1,%0\;%#";
>>
>> I observed that init_cumulative_args is called first for all the
>> functions once they are done then the above pattern for all the
>> instructions are called so my global variable is not useful.
>>
>> Can you help me how to exactly emit bk instruction from the pattern
>> when super function is called.
>
>
> Again I just have to say: look at the rs6000 port. Look at the rs6000
> call instruction. Look at how it decides whether to do a longcall or
> not.
>
> Ian