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

[Chandler Carruth]

On Wed, Apr 15, 2015 at 11:41 AM Mark Heffernan <meheff at google.com> wrote:

> 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:
>
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-March/083398.html
>
> 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.
>

This is exactly the point I was trying to make, and the right approach IMO.
Sorry if it was unclear.

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.

Doing something late in the pipeline to separate things out is a wonderful
way to balance these tradeoffs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150415/768b8609/attachment.html>