This is the mail archive of the
mailing list for the GCC project.
Re: Optimized Allocation of Argument registers
- From: Vladimir Makarov <vmakarov at redhat dot com>
- To: Ajit Kumar Agarwal <ajit dot kumar dot agarwal at xilinx dot com>, gcc Mailing List <gcc at gcc dot gnu dot org>, Jeff Law <law at redhat dot com>
- 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, 25 Nov 2014 16:15:15 -0500
- Subject: Re: Optimized Allocation of Argument registers
- Authentication-results: sourceware.org; auth=none
- References: <2f1c83a90d8840f8ba274d17ecf830fd at BY2FFO11FD054 dot protection dot gbl> <546A5A06 dot 30600 at redhat dot com> <ede066bf2b76498abf1e40da33233edf at BN1AFFO11FD049 dot protection dot gbl>
On 11/24/2014 06:47 AM, Ajit Kumar Agarwal wrote:
> 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.
It is hard to implement as you need to change already generated code (in
callees or callers depending in what order you are generating code for
functions in the call graph). You can not decide what you will do
without RA at least in one function (caller or callee). Although some
rough heuristics are possible on existing call graph level but I guess
they will probably hurt more than improve the code because the
estimation will be very inaccurate.
Although if you create an infrastructure to do such things (having RTLs
of all functions compiled). It could be useful for other projects too,
e.g. for Minimum Cost Interprocedural Register Allocation (see
is more general approach to what you propose.