[all-commits] [llvm/llvm-project] 3f3656: [SVE][CodeGen] Fix scalable vector issues in DAGTy...

[david-arm via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 3f36561f69fd62c3f96e3575835e86187889859d
      https://github.com/llvm/llvm-project/commit/3f36561f69fd62c3f96e3575835e86187889859d
  Author: David Sherwood <david.sherwood at arm.com>
  Date:   2020-08-19 (Wed, 19 Aug 2020)

  Changed paths:
    M llvm/include/llvm/Support/TypeSize.h
    M llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp
    M llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp
    M llvm/test/CodeGen/AArch64/sve-ld1-addressing-mode-reg-imm.ll
    M llvm/test/CodeGen/AArch64/sve-split-load.ll

  Log Message:
  -----------
  [SVE][CodeGen] Fix scalable vector issues in DAGTypeLegalizer::GenWidenVectorLoads

In DAGTypeLegalizer::GenWidenVectorLoads the algorithm assumes it only
ever deals with fixed width types, hence the offsets for each individual
store never take 'vscale' into account. I've changed the code in that
function to use TypeSize instead of unsigned for tracking the remaining
load amount. In addition, I've changed the load loop to use the new
IncrementPointer helper function for updating the addresses in each
iteration, since this handles scalable vector types.

Also, I've added report_fatal_errors in GenWidenVectorExtLoads,
TargetLowering::scalarizeVectorLoad and TargetLowering::scalarizeVectorStores,
since these functions currently use a sequence of element-by-element
scalar loads/stores. In a similar vein, I've also added a fatal error
report in FindMemType for the case when we decide to return the element
type for a scalable vector type.

I've added new tests in

  CodeGen/AArch64/sve-split-load.ll
  CodeGen/AArch64/sve-ld-addressing-mode-reg-imm.ll

for the changes in GenWidenVectorLoads.

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