This patch adds functionality for recording and replaying the execution of OpenMP offload kernels, based on an original implementation by Steve Rangel. The patch extends libomptarget to extract a json description of the kernel, the device image binary, and a device memory snapshot before and after the execution of a recorded kernel. Kernel recording/replaying in libomptarget is controlled through env vars (LIBOMPTARGET_RECORD, LIBOMPTARGET_REPLAY). It provides a tool, llvm-omp-kernel-replay, for replaying a kernel using the extracted information with the ability to verify replayed execution using the post-execution device memory snapshot, also supporting changing the number of teams/threads for replaying.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I have a lot of style/organization comments but nothing major. If nobody has a conceptual problem we merge this in once the code is reorganized and then take it from there.
openmp/libomptarget/plugins-nextgen/common/PluginInterface/PluginInterface.cpp | ||
---|---|---|
220 | Let's put all these code snippets into a namespace or struct as static functions. if (isRecording()) recording::saveImage(Image, Name); Since there is state associated with recording, e.g., the memory pointers, we might even want a struct if (RecordReplay.isRecording()) RecordReplay.saveImage(Image, Name); | |
383 | I'd start at more than 8Gb, and I also would like to catch 512Mb and such. Maybe we want a list of "common/known" memory sizes? 64, 32, 24, 20, 16, 10, 8, 6, 4, 2, 1, .5, .25, something like that? (Not that I know how much memory GPUs have...) | |
622 | I imagine this needs to be integrated into the memory manager at some point to support free. | |
737 | These certainly need to go into some sort of helper functions. | |
openmp/libomptarget/src/interface.cpp | ||
249 | Documentation. | |
openmp/libomptarget/src/omptarget.cpp | ||
1755 | No need for the block. | |
openmp/libomptarget/tools/kernelreplay/llvm-omp-kernel-replay.cpp | ||
55 | This is potentially user facing, MB and such doesn't mean much. | |
67 | Add a TODO that we should warn if the value was set before and is now changed. | |
110 | I'm not 100% sold on the env var approach but I don't see a nice alternative that is not invasive. | |
124 | DeviceId needs to be stored and read I assume. We might also want a cmd line option. |
openmp/libomptarget/plugins-nextgen/common/PluginInterface/PluginInterface.cpp | ||
---|---|---|
373 | Are we deallocating this memory buffer? If that's handled by the memory manager, this memory will automatically be freed at manager's finalization. But anyway, I think it's a good practice if we delete it during device deinitialization. | |
620 | I've several doubts/questions because I'm surely missing some context. I'm sorry if these comments do not apply in record/replay mode:
| |
openmp/libomptarget/plugins-nextgen/common/PluginInterface/PluginInterface.h | ||
417 ↗ | (On Diff #478623) | Could we rename the envars to OMPX_RecordKernel and OMPX_ReplayKernel, as the rest of envars? |
openmp/libomptarget/plugins-nextgen/common/PluginInterface/PluginInterface.cpp | ||
---|---|---|
620 | Thank you for feedback, always welcome!
| |
737 | I'm not sure what you mean by filtering | |
openmp/libomptarget/tools/kernelreplay/llvm-omp-kernel-replay.cpp | ||
110 | I couldn't think of a better alternative either. I'm using setenv which is unix specific, I couldn't find a portable interface in LLVM. I ended up adding an env var for saving the kernel device memory output, thinking that it may be the case that we don't want to save the output even when recording. |
LG, I think we can address remaining issues in-tree which makes it easier to test it.
openmp/libomptarget/src/interface.cpp | ||
---|---|---|
259 | Nit: formatting. |
Let's put all these code snippets into a namespace or struct as static functions.
Then they are not "in the way" of the main logic.
Since there is state associated with recording, e.g., the memory pointers, we might even want a struct