This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: Optimized Allocation of Argument registers
- From: Ajit Kumar Agarwal <ajit dot kumar dot agarwal at xilinx dot com>
- To: Vladimir Makarov <vmakarov at redhat dot com>, gcc Mailing List <gcc at gcc dot gnu dot org>
- Cc: Vinod Kathail <vinodk at xilinx dot com>, Shail Aditya Gupta <shailadi at xilinx dot com>, Vidhumouli Hunsigida <vidhum at xilinx dot com>, "Nagaraju Mekala" <nmekala at xilinx dot com>
- Date: Tue, 18 Nov 2014 13:30:54 +0000
- Subject: RE: Optimized Allocation of Argument registers
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=pass (sender IP is 149.199.60.83) smtp dot mailfrom=ajit dot kumar dot agarwal at xilinx dot com;
- References: <2f1c83a90d8840f8ba274d17ecf830fd at BY2FFO11FD054 dot protection dot gbl> <546A5A06 dot 30600 at redhat dot com>
-----Original Message-----
From: Vladimir Makarov [mailto:vmakarov@redhat.com]
Sent: Tuesday, November 18, 2014 1:57 AM
To: Ajit Kumar Agarwal; gcc Mailing List
Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala
Subject: Re: Optimized Allocation of Argument registers
On 2014-11-17 8:13 AM, Ajit Kumar Agarwal wrote:
> Hello All:
>
> I was looking at the optimized usage and allocation to argument registers. There are two aspects to it as follows.
>
> 1. We need to specify the argument registers as followed by ABI in the target specific code. Based on the function
> argument registers defined in the target dependent code the function argument registers are passed. If the
> number of argument registers defined in the Architecture is large say 6/8 function argument registers.
> Most of the time in the benchmarks we don't pass so many arguments and the number of arguments passed
> is quite less. Since we reserve the function arguments as specified
> in the target specific code for the given architecture, leads to unoptimized usage as this function argument registers will not be used in the function.
> Thus we need to steal some of the arguments registers and have the
> usage of those in the function depending on the support of the number of function argument registers. The stealing of function argument registers will
> lead more number of registers available that are to be used in the function and leading to less spill and fetch.
>
>>The argument registers should be not reserved. They should be present in RTL and RA allocator will figure out itself when it can use them.
>>That is how other ports work.
Thanks Vladimir for Clarifications.
> 2. The other aspect of the function argument registers is not spill
> and fetch the argument registers as they are live across the function
> call. But the liveness is limited to certain point of the called
> function after that point the function argument registers are not live
> and can be used inside the called function. Other aspect is if there is a shortage of registers than can the function argument registers should be used as spill candidate? Will this lead to the optimized code.
>
>
>>You can remove unnecessary code to save/restore arg registers around calls if you can figure out that they are not used in called functions.
>> There is already code for this written by Tom de Vries. So you can use it.
Is the code written by Tom de Vries already a part of trunk? Could you please give the pointer to this part of code.
Thanks & Regards
Ajit