[PATCH] Improve the cost evaluation of LSR

[Xinliang David Li]

On Fri, May 1, 2015 at 10:30 AM, Quentin Colombet <qcolombet at apple.com>
wrote:

> Hi Wei,
>
> The short story is: I do not think this is the way to go.
>
> Now, the long story.
>
> I have mixed feelings on the direction of the approach. On one hand, I
> also think we should optimize for performance as long as register pressure
> is not a problem. On the other hand, the register pressure estimate at this
> level too rough to make any useful decisions.
>

That is a pretty strong statement (about usefulness of register pressure
estimate) :)   I think it is probably reasonably good for cases where
pressure is very low and very high -- and this part can be improved
independently.

Your current approach illustrate this point. Indeed, IIRC NumRegs only
> gives you the number of registers you need to materialize the formulae, we
> do not consider how many register we already need in the loop or through
> the loop. Therefore, I believe by tweaking the body of the loop in your
> motivating example (i.e., adding just enough live ranges), we can bloat the
> register pressure with the new rating and have spill within the loop,
> whereas we wouldn’t with the previous rating.
>

If we don't want spills, but spills occur, then it is matter of tuning
register pressure estimation -- can even be made more conservative. In
fact, if we consider spills in the overall cost, we can even deliberately
allow some spills to reduce overall cost (but that requires very precise
pressure estimate).


>
> I also mentioned that in the related PR, but I believe the way to go is:
> not to care on register pressure and just rate the cost of the loop body.
> However, this implies the backends are able to recover from the register
> pressure bloat and I believe we are not quite here.
>
>
The cost should include 'potential' spills due to register pressure.



> *How do we move?
>
> I would suggest we add an internal option to make LSR more aggressive
> w.r.t. to register pressure, and fix all the problems that rise in the
> backends. Then, we can turn that option on by default.
>

We want to generate optimal code sequence with minimal cost --- that is not
equivalent to 'the most aggressive LSR'.   Do we already know possible ways
to fix the problem once the damage is already made (high reg pressure ...)?


>
> - What if other people still believe this is the right way to move?
>
> Like I said, I do not think this is the right way to go. Now, if other
> people believe it is, I would at least expect that you supply more details
> numbers. In particular, what are the actual numbers (not just the geometric
> means) and what are the regressions, why we do not care or how do we plan
> to fix them.
>

I suggest Wei to refactor the change in a way so that it can be turned
on/off with an option. When that is ready, the community can help with the
performance testing on their favorite platforms with their favorite
benchmarks. It may turns out to be better for everyone, who knows :)

David




>
> Cheers,
> -Quentin
>
>
> REPOSITORY
>   rL LLVM
>
> http://reviews.llvm.org/D9429
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150501/4fd6086b/attachment.html>