[all-commits] [llvm/llvm-project] 467e5c: [SVE][AArch64] Fix TypeSize warning in loop vector...

[Joe Ellis via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 467e5cf40f5da942419624d6a722567976b28a45
      https://github.com/llvm/llvm-project/commit/467e5cf40f5da942419624d6a722567976b28a45
  Author: Joe Ellis <joe.ellis at arm.com>
  Date:   2020-10-26 (Mon, 26 Oct 2020)

  Changed paths:
    M llvm/lib/Analysis/Loads.cpp
    M llvm/lib/Transforms/Vectorize/LoopVectorizationLegality.cpp
    A llvm/test/Transforms/LoopVectorize/AArch64/sve-scalable-load-in-loop.ll

  Log Message:
  -----------
  [SVE][AArch64] Fix TypeSize warning in loop vectorization legality

The warning would fire when calling isDereferenceableAndAlignedInLoop
with a scalable load. Calling isDereferenceableAndAlignedInLoop with a
scalable load would result in the use of the now deprecated implicit
cast of TypeSize to uint64_t through the overloaded operator.

This patch fixes this issue by:

- no longer considering vector loads as candidates in
  canVectorizeWithIfConvert. This doesn't make sense in the context of
  identifying scalar loads to vectorize.

- making use of getFixedSize inside isDereferenceableAndAlignedInLoop --
  this removes the dependency on the deprecated interface, and will
  trigger an assertion error if the function is ever called with a
  scalable type.

Reviewed By: sdesmalen

Differential Revision: https://reviews.llvm.org/D89798


  Commit: 0383a1a8c230581aec4f2d9d4bfb5f5ed32d2bf5
      https://github.com/llvm/llvm-project/commit/0383a1a8c230581aec4f2d9d4bfb5f5ed32d2bf5
  Author: Joe Ellis <joe.ellis at arm.com>
  Date:   2020-10-26 (Mon, 26 Oct 2020)

  Changed paths:
    M llvm/include/llvm/Analysis/TargetTransformInfoImpl.h
    A llvm/test/Analysis/CostModel/AArch64/cost-scalable-vector-gep.ll

  Log Message:
  -----------
  [SVE][AArch64] Fix TypeSize warning in GEP cost analysis

The warning would fire when calling getGEPCost for analyzing the cost of
a GEP instruction. This would result in the use of the now deprecated
implicit cast of TypeSize to uint64_t through the overloaded operator.

This patch fixes the issue by using getKnownMinSize instead of the
implicit cast. This is possible because the code is already
scalable-vector aware. The semantic behaviour of the code is unchanged
by this patch.

Reviewed By: sdesmalen, fpetrogalli

Differential Revision: https://reviews.llvm.org/D89872


  Commit: 0f8350559325db35e0ee3423db5d29113e4eec12
      https://github.com/llvm/llvm-project/commit/0f8350559325db35e0ee3423db5d29113e4eec12
  Author: Joe Ellis <joe.ellis at arm.com>
  Date:   2020-10-26 (Mon, 26 Oct 2020)

  Changed paths:
    M llvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp
    A llvm/test/Transforms/InstCombine/gep-can-replace-gep-idx-with-zero-typesize.ll

  Log Message:
  -----------
  [SVE][InstCombine] Fix TypeSize warning in canReplaceGEPIdxWithZero

The warning would fire when calling canReplaceGEPIdxWithZero on a GEP
whose source element type is a scalable vector. The size of scalable
vector types is not known, so this optimization cannot be performed.

This patch fixes the issue by:

- bailing out early in this routine if the GEP instruction's source
  element type is a scalable vector.

- making use of getFixedSize -- this removes the dependency on the
  deprecated interface.

Reviewed By: fpetrogalli

Differential Revision: https://reviews.llvm.org/D89968


  Commit: bf60bb26ecbf4dace2a03886180be66b3ef5608a
      https://github.com/llvm/llvm-project/commit/bf60bb26ecbf4dace2a03886180be66b3ef5608a
  Author: Joe Ellis <joe.ellis at arm.com>
  Date:   2020-10-26 (Mon, 26 Oct 2020)

  Changed paths:
    M llvm/lib/Analysis/VectorUtils.cpp
    A llvm/test/Analysis/LoopAccessAnalysis/gep-induction-operand-typesize-warning.ll

  Log Message:
  -----------
  [SVE] Fix TypeSize warning in llvm::getGEPInductionOperand

We do not need to use the implicit cast here. We can instead can rely on
a comparison between two TypeSize objects instead. This algorithm will
work fine with scalable vectors.

Reviewed By: DavidTruby

Differential Revision: https://reviews.llvm.org/D90146


Compare: https://github.com/llvm/llvm-project/compare/66d03af88c2e...bf60bb26ecbf