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

[Xinliang David Li]

On Wed, Apr 15, 2015 at 10:01 AM, Quentin Colombet <qcolombet at apple.com>
wrote:

>
> 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> 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.
>

I agree with this.  We have many evidence that current aggressive merging
hurts, but no performance data show regressions with Wei's approach.  When
new evidence comes in, further tuning can be done -- and possibly in a more
unified way.

David



>
> 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
>> 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
>
>
>
> _______________________________________________
> 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/6f013c0f/attachment.html>