[all-commits] [llvm/llvm-project] 59c4d5: [SVE] Fix InstCombinerImpl::PromoteCastOfAllocatio...

[david-arm via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 59c4d5aad060927fa95b917c11aad4e310849a4b
      https://github.com/llvm/llvm-project/commit/59c4d5aad060927fa95b917c11aad4e310849a4b
  Author: David Sherwood <david.sherwood at arm.com>
  Date:   2020-09-23 (Wed, 23 Sep 2020)

  Changed paths:
    M llvm/lib/Transforms/InstCombine/InstCombineCasts.cpp
    A llvm/test/Transforms/InstCombine/AArch64/sve-cast-of-alloc.ll

  Log Message:
  -----------
  [SVE] Fix InstCombinerImpl::PromoteCastOfAllocation for scalable vectors

In this patch I've fixed some warnings that arose from the implicit
cast of TypeSize -> uint64_t. I tried writing a variety of different
cases to show how this optimisation might work for scalable vectors
and found:

1. The optimisation does not work for cases where the cast type
is scalable and the allocated type is not. This because we need to
know how many times the cast type fits into the allocated type.
2. If we pass all the various checks for the case when the allocated
type is scalable and the cast type is not, then when creating the
new alloca we have to take vscale into account. This leads to
sub-optimal IR that is worse than the original IR.
3. For the remaining case when both the alloca and cast types are
scalable it is hard to find examples where the optimisation would
kick in, except for simple bitcasts, because we typically fail the
ABI alignment checks.

For now I've changed the code to bail out if only one of the alloca
and cast types is scalable. This means we continue to support the
existing cases where both types are fixed, and also the specific case
when both types are scalable with the same size and alignment, for
example a simple bitcast of an alloca to another type.

I've added tests that show we don't attempt to promote the alloca,
except for simple bitcasts:

  Transforms/InstCombine/AArch64/sve-cast-of-alloc.ll

Differential revision: https://reviews.llvm.org/D87378