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

[Chandler Carruth]

On Wed, Apr 15, 2015 at 2:13 AM Nick Lewycky <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.


>
> > 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
> 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/d1a88417/attachment.html>