aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/MachineFunction.cpp
diff options
context:
space:
mode:
authorLuke Lau <luke@igalia.com>2023-06-06 13:16:13 +0200
committerLuke Lau <luke@igalia.com>2023-06-28 22:45:04 +0100
commit742fb8b5c7036409f08ab0706f00057ac29ac773 (patch)
treeab66a7b7eaae8abf146686367b58a9620b345de2 /llvm/lib/CodeGen/MachineFunction.cpp
parent9ad29e7b3df4b6f8cb4e46d148855dd60c54f13f (diff)
downloadllvm-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