diff options
| author | David Sherwood <david.sherwood@arm.com> | 2020-08-12 14:16:22 +0100 |
|---|---|---|
| committer | David Sherwood <david.sherwood@arm.com> | 2020-08-19 07:54:32 +0100 |
| commit | 3f36561f69fd62c3f96e3575835e86187889859d (patch) | |
| tree | aa6202dc1e8329677d88e62d06d115b73d52056b /llvm/tools/llvm-objdump/llvm-objdump.cpp | |
| parent | b32f203edc8579d4c0023007880293c3f9404fb7 (diff) | |
| download | llvm-3f36561f69fd62c3f96e3575835e86187889859d.zip llvm-3f36561f69fd62c3f96e3575835e86187889859d.tar.gz llvm-3f36561f69fd62c3f96e3575835e86187889859d.tar.bz2 | |
[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
Diffstat (limited to 'llvm/tools/llvm-objdump/llvm-objdump.cpp')
0 files changed, 0 insertions, 0 deletions