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]
Other format: [Raw text]

Re: Optimized Allocation of Argument registers


Ajit,

Please check it out  the -fshrink-wrap option.


~Umesh

On Mon, Nov 24, 2014 at 5:17 PM, Ajit Kumar Agarwal
<ajit.kumar.agarwal@xilinx.com> wrote:
> All:
>
> The optimization of reducing save and restore of the callee and caller saved register has been the attention Of
> increasing the performance of the benchmark. The callee saved registers is saved at the entry and restore at the
> exit of the procedure if the register is reused inside the procedure whereas the caller save registers at the Caller site
> is saved before the call and the restore after the variable is live and spans through the call.
>
> The GCC port has done some optimization whereas the call-used registers are live inside the procedure and has been
> set as 1 bit then it will not be saved and restored. This is based on the data flow analysis.
>
> The callee saved registers is useful when there all multiple calls in the call graph whereas the caller save registers are
> useful if the call is the leaf procedure then the saving before the call and restore after the call will be useful  and increases
>  the performance.
>
> By traversing the call graph in depth-first-order and the bottom-up approach we can propagate the save and restore
> At the procedure entry and exit to the upper regions of the call graph which reduces the save and restore at all the lower
> Regions across the various lower calls. These decision can be made based on the frequency of the call in the call graph as
> Proposed by Fred Chow.
>
> Another approach to reducing the save and restore at the procedure entry and exit is moving the save and restore from
> The procedure entry to the active regions where the variable is Live inside the procedure based on the data flow analysis
> And thus improve the performance of many benchmarks as proposed by Fred Chow.
>
> The propagation of save and restore from the lower regions of the call graph to the upper regions is not implemented in
> The GCC framework and also the moving the save and restore to the active region of Liveness inside the procedure from
> The entry and exit is not implemented inside the GCC framework. Can this be proposed and implemented in GCC framework?
>
> For the open procedure whereas the indirect calls, recursive calls and the external linkage calls cannot be optimized and in
> The open case the save and restore at the entry and exit of the procedure is applied. But for the open procedure if all the
> Lower calls in the call-graph is closed and resolved through call-graph, the save and restore can be propagate to the upper
> Region in the open procedures from the lower region of the calls which are closed and resolved. This can also improve the
> Performance of many benchmarks and can this be proposed and implemented in GCC framework?
>
> Let me know what do you think.
>
> Thanks & Regards
> Ajit
>
> -----Original Message-----
> From: Ajit Kumar Agarwal
> Sent: Tuesday, November 18, 2014 7:01 PM
> To: 'Vladimir Makarov'; gcc Mailing List
> Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala
> Subject: RE: Optimized Allocation of Argument registers
>
>
>
> -----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


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