[PATCH] D106352: [InstCombine] Fold (select C, (gep (gep Ptr, Idx0), Idx1), (gep Ptr, Idx0)) -> (gep Ptr, (select C, Idx0+Idx1, Idx0)) (PR51069)

[Philip Reames via Phabricator via llvm-commits]

reames added a comment.

In D106352#2890033 <https://reviews.llvm.org/D106352#2890033>, @lebedev.ri wrote:

> In D106352#2890021 <https://reviews.llvm.org/D106352#2890021>, @lebedev.ri wrote:
>
>> I feel like `gep (gep Ptr, Idx0), Idx1  --> gep Ptr, Idx0+Idx1` is obviously a standalone fold that should be elsewhere in instcombine.
>
> ... and while we clearly don't have that fold (https://godbolt.org/z/56asoz3ch),
> i realize it wouldn't help here, since `%gep1` has extra use in `select`.

I think Roman is onto something here.  And maybe I'm missing something, but I don't see the extra use he's talking about in the *optimized* IR.

Here's the current output of test2c:
; CHECK-NEXT:    [[GEP1:%.*]] = getelementptr inbounds i32, i32* [[P:%.*]], i64 [[X:%.*]]
; CHECK-NEXT:    [[ICMP:%.*]] = icmp ugt i64 [[X]], [[Y:%.*]]
; CHECK-NEXT:    [[SEL_IDX:%.*]] = select i1 [[ICMP]], i64 0, i64 6
; CHECK-NEXT:    [[SEL:%.*]] = getelementptr i32, i32* [[GEP1]], i64 [[SEL_IDX]]
; CHECK-NEXT:    ret i32* [[SEL]]

Shouldn't a (gep (gep p, idx1), idx2) -> gep p, (idx1+idx2) rule catch this case just fine?   The only real downside I see is that we loose the inbounds on the first gep.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D106352/new/

https://reviews.llvm.org/D106352