aboutsummaryrefslogtreecommitdiff
path: root/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
diff options
context:
space:
mode:
authorFraser Cormack <fraser@codeplay.com>2021-03-03 07:50:49 +0000
committerFraser Cormack <fraser@codeplay.com>2021-03-04 09:21:10 +0000
commitd8e1d2ebf47f8621cc17b5dd2401db95647554fb (patch)
tree9ff3c0c8d93f9dcf653b6bbe2837393b45d669cd /lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
parent1bdb636661d473d731b9a0ab8d9b124037469306 (diff)
downloadllvm-d8e1d2ebf47f8621cc17b5dd2401db95647554fb.zip
llvm-d8e1d2ebf47f8621cc17b5dd2401db95647554fb.tar.gz
llvm-d8e1d2ebf47f8621cc17b5dd2401db95647554fb.tar.bz2
[RISCV] Preserve fixed-length VL on insert_vector_elt in more cases
This patch fixes up one case where the fixed-length-vector VL was dropped (falling back to VLMAX) when inserting vector elements, as the code would lower via ISD::INSERT_VECTOR_ELT (at index 0) which loses the fixed-length vector information. To this end, a custom node, VMV_S_XF_VL, was introduced to carry the VL operand through to the final instruction. This node wraps the RVV vmv.s.x and vmv.s.f instructions, which were being selected by insert_vector_elt anyway. There should be no observable difference in scalable-vector codegen. There is still one outstanding drop from fixed-length VL to VLMAX, when an i64 element is inserted into a vector on RV32; the splat (which is custom legalized) has no notion of the original fixed-length vector type. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D97842
Diffstat (limited to 'lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp')
0 files changed, 0 insertions, 0 deletions