forked from OSchip/llvm-project
71d81e5c8f
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 |
||
|---|---|---|
| .. | ||
| Analysis | ||
| Assembler | ||
| Bindings | ||
| Bitcode | ||
| BugPoint | ||
| CodeGen | ||
| DebugInfo | ||
| Demangle | ||
| Examples | ||
| ExecutionEngine | ||
| Feature | ||
| FileCheck | ||
| Instrumentation | ||
| Integer | ||
| JitListener | ||
| LTO | ||
| Linker | ||
| MC | ||
| Object | ||
| ObjectYAML | ||
| Other | ||
| SafepointIRVerifier | ||
| SymbolRewriter | ||
| TableGen | ||
| ThinLTO/X86 | ||
| Transforms | ||
| Unit | ||
| Verifier | ||
| YAMLParser | ||
| tools | ||
| .clang-format | ||
| CMakeLists.txt | ||
| TestRunner.sh | ||
| lit.cfg.py | ||
| lit.site.cfg.py.in | ||