[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