[PATCH] D125845: [InstCombine] Canonicalize GEP of GEP by swapping constant-indexed GEP to the back
Bjorn Pettersson via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Nov 28 10:17:46 PST 2022
bjope added inline comments.
================
Comment at: llvm/test/Transforms/InstCombine/gep-canonicalize-constant-indices.ll:33
;
%1 = getelementptr inbounds [4 x i32], ptr %p, i64 %a, i64 1
%2 = getelementptr inbounds i32, ptr %p, i64 %b
----------------
spatel wrote:
> spatel wrote:
> > I don't know what this test and the next one are supposed to show. %1 is dead code, so it gets eliminated before anything else might have happened.
> I'm more confused now. The test had 1 GEP, but now it has 2 - how is that better?
> I'm more confused now. The test had 1 GEP, but now it has 2 - how is that better?
This question is still not answered afaict. We now get two non-inbound GEP:s instead of one inbounds GEP. Given that there are no other GEP:s etc that can be simplified (as in this test case) that doesn't look like an improvement?
And I guess loosing the inbounds property can be bad in general when doing this canonicalizations. Do you have any examples when you see a performance improvement when rewriting inbound GEP:s into non-inbound GEP:s? Given the amount of complaints about seen regressions it would be nice to hear what kinds of benchmarks that were done and if you tried to limit it to cases when instruction count didn't increase, or when it would turn X inbound GEP:s into X or more non-inbound GEP:s.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D125845/new/
https://reviews.llvm.org/D125845
More information about the llvm-commits
mailing list