summaryrefslogtreecommitdiffstats
path: root/clang/lib/Serialization/ASTWriterDecl.cpp
diff options
context:
space:
mode:
authorYonghong Song <yhs@fb.com>2018-07-25 22:40:02 +0000
committerYonghong Song <yhs@fb.com>2018-07-25 22:40:02 +0000
commit71d81e5c8fcebb7663973d686ac1ad3309502f4b (patch)
treeb736fbd18247bcced3522642ad47914ce594235d /clang/lib/Serialization/ASTWriterDecl.cpp
parent99ca3c0a617337902c2b2006231acc64397d9df3 (diff)
downloadbcm5719-llvm-71d81e5c8fcebb7663973d686ac1ad3309502f4b.tar.gz
bcm5719-llvm-71d81e5c8fcebb7663973d686ac1ad3309502f4b.zip
bpf: new option -bpf-expand-memcpy-in-order to expand memcpy in order
Some BPF JIT backends would want to optimize memcpy in their own architecture specific way. However, at the moment, there is no way for JIT backends to see memcpy semantics in a reliable way. This is due to LLVM BPF backend is expanding memcpy into load/store sequences and could possibly schedule them apart from each other further. So, BPF JIT backends inside kernel can't reliably recognize memcpy semantics by peephole BPF sequence. This patch introduce new intrinsic expand infrastructure to memcpy. To get stable in-order load/store sequence from memcpy, we first lower memcpy into BPF::MEMCPY node which then expanded into in-order load/store sequences in expandPostRAPseudo pass which will happen after instruction scheduling. By this way, kernel JIT backends could reliably recognize memcpy through scanning BPF sequence. This new memcpy expand infrastructure is gated by a new option: -bpf-expand-memcpy-in-order Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Jiong Wang <jiong.wang@netronome.com> Signed-off-by: Yonghong Song <yhs@fb.com> llvm-svn: 337977
Diffstat (limited to 'clang/lib/Serialization/ASTWriterDecl.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud