diff options
author | David Sherwood <david.sherwood@arm.com> | 2021-05-04 13:58:02 +0100 |
---|---|---|
committer | David Sherwood <david.sherwood@arm.com> | 2021-05-26 09:54:26 +0100 |
commit | 9c766f4090d19e3e2f56e87164177f8c3eba4b96 (patch) | |
tree | acdb55124e1d492c6fc41b80988b32e0ff506b11 /lldb/source/Target/ModuleCache.cpp | |
parent | b99f892b025b553680c7e5dbcf15ab7301e3fa57 (diff) | |
download | llvm-9c766f4090d19e3e2f56e87164177f8c3eba4b96.zip llvm-9c766f4090d19e3e2f56e87164177f8c3eba4b96.tar.gz llvm-9c766f4090d19e3e2f56e87164177f8c3eba4b96.tar.bz2 |
[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
Diffstat (limited to 'lldb/source/Target/ModuleCache.cpp')
0 files changed, 0 insertions, 0 deletions