[all-commits] [llvm/llvm-project] 9c766f: [InstCombine] Fold extractelement + vector GEP wit...

[david-arm via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 9c766f4090d19e3e2f56e87164177f8c3eba4b96
      https://github.com/llvm/llvm-project/commit/9c766f4090d19e3e2f56e87164177f8c3eba4b96
  Author: David Sherwood <david.sherwood at arm.com>
  Date:   2021-05-26 (Wed, 26 May 2021)

  Changed paths:
    M llvm/lib/Transforms/InstCombine/InstCombineVectorOps.cpp
    A llvm/test/Transforms/InstCombine/gep-vector-indices.ll
    M llvm/test/Transforms/InstCombine/vec_demanded_elts-inseltpoison.ll
    M llvm/test/Transforms/InstCombine/vec_demanded_elts.ll
    M llvm/test/Transforms/InstCombine/vec_gep_scalar_arg-inseltpoison.ll
    M llvm/test/Transforms/InstCombine/vec_gep_scalar_arg.ll

  Log Message:
  -----------
  [InstCombine] Fold extractelement + vector GEP with one use

We sometimes see code like this:

Case 1:
  %gep = getelementptr i32, i32* %a, <2 x i64> %splat
  %ext = extractelement <2 x i32*> %gep, i32 0

or this:

Case 2:
  %gep = getelementptr i32, <4 x i32*> %a, i64 1
  %ext = extractelement <4 x i32*> %gep, i32 0

where there is only one use of the GEP. In such cases it makes
sense to fold the two together such that we create a scalar GEP:

Case 1:
  %ext = extractelement <2 x i64> %splat, i32 0
  %gep = getelementptr i32, i32* %a, i64 %ext

Case 2:
  %ext = extractelement <2 x i32*> %a, i32 0
  %gep = getelementptr i32, i32* %ext, i64 1

This may create further folding opportunities as a result, i.e.
the extract of a splat vector can be completely eliminated. Also,
even for the general case where the vector operand is not a splat
it seems beneficial to create a scalar GEP and extract the scalar
element from the operand. Therefore, in this patch I've assumed
that a scalar GEP is always preferrable to a vector GEP and have
added code to unconditionally fold the extract + GEP.

I haven't added folds for the case when we have both a vector of
pointers and a vector of indices, since this would require
generating an additional extractelement operation.

Tests have been added here:

  Transforms/InstCombine/gep-vector-indices.ll

Differential Revision: https://reviews.llvm.org/D101900