<div dir="ltr"><div class="gmail_quote">On Wed, Apr 15, 2015 at 11:41 AM Mark Heffernan <<a href="mailto:meheff@google.com">meheff@google.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There was a discussion on the mailing list about the exact issue this patch is addressing.  We (Google team working on NVPTX backend) ran into this same issue as did someone (Francois Pichet) working with the ppc backend.  Here's the link to the discussion:<br>
<br>
<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-March/083398.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-March/083398.html</a><br>
<br>
I initially proposed what your patch does.  That is, don't merge geps unless the indices are constant (in which case the add is folded so no additional instructions are potentially created in loops).  However, after some discussion we came to the conclusion that the gep merging is a good canonicalization which we want to do.  Instead a better approach might be to split GEPs (undoing the early GEP merge) very late, right before codegen, if it is determined to be profitable.  This way, all the intermediate passes get the advantage of the canonicalization, while still being able to do LICM/CSE on GEP subexpressions which the gep merge had prevented.<br></blockquote><div><br></div><div>This is exactly the point I was trying to make, and the right approach IMO. Sorry if it was unclear.</div><div><br></div><div>The idea is that if we don't want to merge early in the optimizer, that should be because it is a better canonical form, and we should be willing to *split* early in the optimizer to ensure we always produce it. I'm completely in agreement that we probably don't want to split it. But that means we need to find some other way to address the performance problems.</div><div><br></div><div>Doing something late in the pipeline to separate things out is a wonderful way to balance these tradeoffs.</div></div></div>