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

[Nick Lewycky]

Quentin Colombet wrote:

> The thing with the "both constants" approach is that we may miss some cases where an addressing mode may apply. In particular, on x86, when one argument of the add is a constant, we would be able to match reg1 + reg2 + displacement.

> 

> That being said, your numbers imply this is not a problem in practice, and most targets do not support reg1 + reg2 + reg3/imm addressing mode. Anyway, we could recover from that later on if needed.

> 

> So LGTM.


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? We already have other problems where we introduce loop 
carried dependencies where ones previously didn't exist, shouldn't we 
approach this by adding an API to detect those and then making 
transforms conditional on that?

Nick

> Thanks Wei!

> -Quentin

> 

> REPOSITORY

> 

>   rL LLVM

> 

> http://reviews.llvm.org/D8911

> 

> EMAIL PREFERENCES

> 

>   http://reviews.llvm.org/settings/panel/emailpreferences/



REPOSITORY
  rL LLVM

http://reviews.llvm.org/D8911

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/