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


On 11/24/2014 06:47 AM, Ajit Kumar Agarwal 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.
>
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
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.5914) which
is more general approach to what you propose.


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