[llvm-dev] A thought to improve IPRA

[vivek pandya via llvm-dev]

Hello LLVM Developers,

I have a thought to improve IPRA and I would like summaries discussion on
IRC regarding that so we can develop an idea out of that if it really helps.

So idea is to have more callee saved registers at infrequently called leaf
procedures and try provide more registers to procedures which are in upper
region of the call graph. But as pointed out by Quentin this optimization
may help in context of "true" IPRA but in our case we may not require this.
But I think that it can improve performance in current IPRA. I explain both
arguments ( Quentin's and mine) with following example.

Consider following call sequence A->B->C , here C is very less time called
leaf procedure while A is called frequently and B may call C based on some
condition now while propagating actual register usage information from C to
A we almost clobbered most of the registers so in this case as per
Quentin's point we does not hurt the performance as we fall back to CC but
I think we can improve the performance as follows:
If we mark every register preserved by C (i.e having more spill reloads at
procedure entry and exit ) and if this can help  at A. Suppose A requires
more number of distinct registers than CC can provide and if not provided
it will spill variables to memory. Now if we can provide more registers at
A by having more spills at C then we can save spill at A which can be
beneficial because A is frequently called but C is less frequently called
and thus reducing total number of spill/restore in program execution.

However again effect of this optimization will be limited by the scope of
current IPRA (i.e one Module only) because we can' really propagate the
details about more callee saved registers to caller which is defined in
other module, but still it may helpful.

Any thoughts on this ?

Sincerely,
Vivek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160708/1a35e21f/attachment.html>