[PATCH] Fix a performance problem in gep(gep ...) merging

[Quentin Colombet]

> On Apr 15, 2015, at 2:18 AM, Chandler Carruth <chandlerc at google.com> wrote:
> 
> On Wed, Apr 15, 2015 at 2:13 AM Nick Lewycky <nicholas at mxc.ca <mailto:nicholas at mxc.ca>> wrote:
>   So the criterial
> > deciding whether to do the merging for a case is to see whether
> > merging is beneficial. We want to find out all the important cases for
> > which gep merging is beneficial.
> 
> My default assumption is that gep merging is beneficial; the cost
> metrics all assume that fewer instructions is better, your .bc will be
> smaller, your optimizations have fewer instructions to look through,
> some optimizations have limits on how many instructions they will look
> through, etc. We want to find out all the important cases for which gep
> merging is harmful, or find out which cases should have gep splitting.
> 
> Put another way, if having these GEPs split apart is better then why
> doesn't the optimizer turn a single GEP into two when that's better?
> Only removing the optimization here can't be the right answer.
> 
> I agree. As Hal said, I'm pretty worried about blocking merging in an ad-hoc way. It seems really likely to create limitations in every part of the optimizer that wants to look through things.
> 
> Unless we have a sufficiently strong heuristic to *split* GEPs, my suspicion is that we don't have the correct heuristic.

Well, Wei’s numbers seem to prove this is not an issue in practice.
I would rather determine the right heuristic on actual motivating examples than sitting on the performance benefits Wei demonstrated.

What would it take to convince you (not you in particular Chandler :)) that Wei’s heuristic is good enough for now?

Would a diff of the binaries showing no regressions on the would test suite for, let say x86_64, arm, aarch64, and PPC, do?
Note: I am talking about binary diff, no need to run.

BTW, I assume Wei, that you already done something similar.
What were the results?

Cheers,
-Quentin

>  
> 
> > Quentin mentioned the beneficial addressing mode case I didn't think
> > of before. And it is possible that I can filter out some testcases
> > from internal benchmarks. working on it right now.
> 
> Sounds good! I've heard the addressing mode matching code is a pain, but
> if we could make it smarter I think that would be better. If you have a
> testcase where GEP merging causes a loss of performance then you also
> have a testcase where the addressing mode matcher is missing something,
> right?
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits <http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>
> _______________________________________________
> 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/20150415/0d2fce90/attachment.html>