We still need the code after stripAndAccumulateConstantOffsets() since
it doesn't handle GEPs of scalable types and non-constant but identical
indexes.
Details
- Reviewers
nikic - Commits
- rG55cf09ae2600: [ValueTracking] Simplify llvm::isPointerOffset()
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
60,140 ms | x64 debian > MLIR.Examples/standalone::test.toy | |
60,030 ms | x64 debian > libFuzzer.libFuzzer::large.test |
Event Timeline
llvm/lib/Analysis/ValueTracking.cpp | ||
---|---|---|
7107 | This will cause issues if Ptr1 and Ptr2 are in differently-sized address spaces. I think just doing Offset2.getSExtValue() - Offset1.getSExtValue() would be fine here. | |
llvm/test/Transforms/MemCpyOpt/opaque-ptr.ll | ||
55 | I think the main motivation for the additional code isn't scalable vectors, but rather cases that have a common non-constant index, like GEP p, x, 0 and GEP p, x, 1. |
llvm/test/Transforms/MemCpyOpt/opaque-ptr.ll | ||
---|---|---|
55 | yes you're right, I was trying to use GEPOperator::collectOffset here but it didn't handle vscale types and that was on my mind when writing the commit message |
This will cause issues if Ptr1 and Ptr2 are in differently-sized address spaces. I think just doing Offset2.getSExtValue() - Offset1.getSExtValue() would be fine here.