diff options
author | Luke Lau <luke@igalia.com> | 2023-06-06 13:16:13 +0200 |
---|---|---|
committer | Luke Lau <luke@igalia.com> | 2023-06-28 22:45:04 +0100 |
commit | 742fb8b5c7036409f08ab0706f00057ac29ac773 (patch) | |
tree | ab66a7b7eaae8abf146686367b58a9620b345de2 /llvm/lib/CodeGen/MachineFunction.cpp | |
parent | 9ad29e7b3df4b6f8cb4e46d148855dd60c54f13f (diff) | |
download | llvm-742fb8b5c7036409f08ab0706f00057ac29ac773.zip llvm-742fb8b5c7036409f08ab0706f00057ac29ac773.tar.gz llvm-742fb8b5c7036409f08ab0706f00057ac29ac773.tar.bz2 |
[DAGCombine] Fold (store (insert_elt (load p)) x p) -> (store x)
If we have a store of a load with no other uses in between it, it's
considered dead and is removed. So sometimes when legalizing a fixed
length vector store of an insert, we end up producing better code
through scalarization than without.
An example is the follow below:
%a = load <4 x i64>, ptr %x
%b = insertelement <4 x i64> %a, i64 %y, i32 2
store <4 x i64> %b, ptr %x
If this is scalarized, then DAGCombine successfully removes 3 of the 4
stores which are considered dead, and on RISC-V we get:
sd a1, 16(a0)
However if we make the vector type legal (-mattr=+v), then we lose the
optimisation because we don't scalarize it.
This patch attempts to recover the optimisation for vectors by
identifying patterns where we store a load with a single insert
inbetween, replacing it with a scalar store of the inserted element.
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D152276
Diffstat (limited to 'llvm/lib/CodeGen/MachineFunction.cpp')
0 files changed, 0 insertions, 0 deletions