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

[Xinliang David Li]

GEP merging enables folding and possible opportunities related to
addressing mode, but I am not convinced it can be considered as a
'canonical form' according to information discovered in the thread so far.
As long as there are cases (which there are) where GEP merging can not
happen, no passes should fully rely on the form (except for the limitation
imposed due to compile time concern) to operate, nor there are evidence
that the merged form can produce more precise analysis result.

David


On Wed, Apr 15, 2015 at 2:16 PM, Chandler Carruth <chandlerc at google.com>
wrote:

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