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

[Nick Lewycky]

Wei Mi wrote:
>> I might be misunderstanding why this patch helps, please bear with me. Is
>> this not a special case of a general problem, mainly that we're merging
>> something into a loop that was previously two operations one inside and one
>> outside the loop? Why wouldn't this problem come up in other ways?
>
> merging something into a loop was not the key problem here. If the
> cost after merging is less than the cost of the target, the merging is
> still beneficial even if the target is inside loop.

OK.

  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.

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