[PATCH] D88788: [SROA] rewritePartition()/findCommonType(): if uses have conflicting type, try getTypePartition() before falling back to largest integral use type (PR47592)
Roman Lebedev via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Sat Oct 3 12:58:23 PDT 2020
lebedev.ri created this revision.
lebedev.ri added reviewers: Carrot, efriedma, MaskRay, jfb.
lebedev.ri added a project: LLVM.
Herald added subscribers: dexonsmith, kbarton, hiraditya, nemanjai.
lebedev.ri requested review of this revision.
InstCombine has a `combineLoadToOperationType()` fold, which has the following comment:
// Try to canonicalize loads which are only ever stored to operate over
// integers instead of any other type. We only do this when the loaded type
// is sized and has a size exactly the same as its store size and the store
// size is a legal integer type.
The obvious caveat is, while that does not create `inttoptr` casts immediately,
it does potentially cause creation of `inttoptr` casts afterwards.
I have reduced the PhaseOrdering test from a real code.
It shows, that running SROA after that InstCombine fold, we do end up with `inttoptr` casts,
because we end up having two loads - one of `i8*` and one of `i64`.
I think it's pretty obvious that it is an undesired outcome.
While there are other solutions, i think we can (at least partially?) mitigate/hide
the problem by teaching SROA to try to use the slice's original struct type
instead of immediately falling back to the largest integral use type.
See https://bugs.llvm.org/show_bug.cgi?id=47592
Repository:
rG LLVM Github Monorepo
https://reviews.llvm.org/D88788
Files:
llvm/lib/Transforms/Scalar/SROA.cpp
llvm/test/Transforms/PhaseOrdering/instcombine-sroa-inttoptr.ll
llvm/test/Transforms/SROA/ppcf128-no-fold.ll
llvm/test/Transforms/SROA/preserve-nonnull.ll
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D88788.296000.patch
Type: text/x-patch
Size: 7509 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20201003/243c4ad5/attachment.bin>
More information about the llvm-commits
mailing list