[LLVMdev] Question about shouldMergeGEPs in InstructionCombining

[Francois Pichet]

I think it would make sense for (1) and (2). I am not sure if (3) is
feasible in instcombine. (I am not too familiar with LoopInfo)

For the Octasic's Opus platform, I modified shouldMergeGEPs in our fork to:

  if (GEP.hasAllZeroIndices() && !Src.hasAllZeroIndices() &&
      !Src.hasOneUse())
    return false;

  return Src.hasAllConstantIndices(); // was return false;

Following that change, I noticed some performance gain for a few specific
tests and no regression at all in our (admittedly limited) benchmarks suite.

Regards,
Francois Pichet, Octasic.

On Thu, Mar 12, 2015 at 4:14 PM, Mark Heffernan <meheff at google.com> wrote:

> Coincidentally, I just ran into this same issue on some of our benchmarks
> for the NVPTX backend.  You have something like this before instcombine:
>
>   %tmp = getelementptr inbounds i32, i32* %input, i64 %offset
> loop:
>   %loop_variant = ...
>   %ptr = getelementptr inbounds i32, i32* %tmp, i64 %loop_variant
>
> Which gets transformed to:
>
> loop:
>   %loop_variant = ...
>   %sum = add nsw i64 %loop_variant, %offset
>   %ptr = getelementptr inbounds i32, i32* %input, i64 %sum
>
> The merge essentially reassociates the loop-variant term (%loop_variant)
> and loop-invariant terms (%input and %offset) in such a way that LICM can't
> remove it.
>
> One idea is to only perform this style of gep merge if at least one of the
> following conditions is true:
> (1) both index terms in the GEP  are constant.  In this case no new add
> instruction is created, instead the constants are folded.
> (2) the GEPs are in the same BB.
> (3) LoopInfo is available, and we know we're not creating a new
> instruction in a (deeper) loop.
>
> What do you think?
>
> Mark
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150312/76632ccb/attachment.html>