[PATCH] D139287: [WIP][OpenMP] Introduce basic JIT support to OpenMP target offloading

Joseph Huber via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Dec 5 08:06:49 PST 2022


jhuber6 added inline comments.


================
Comment at: openmp/libomptarget/plugins-nextgen/common/PluginInterface/JIT.cpp:184
+
+  auto AddStream =
+      [&](size_t Task,
----------------
tianshilei1992 wrote:
> jhuber6 wrote:
> > tianshilei1992 wrote:
> > > jhuber6 wrote:
> > > > tianshilei1992 wrote:
> > > > > Is there any way that we don't write it to a file here?
> > > > Why do we need to invoke LTO here? I figured that we could call the backend directly since we have no need to actually link any filies, and we may not have a need to run more expensive optimizations when the bitcode is already optimized. If you do that then you should be able to just use a `raw_svector_ostream` as your output stream and get the compiled output written to that buffer.
> > > For the purpose of this basic JIT support, we indeed just need backend. However, since we have the plan for super optimization, etc., having an optimization pipeline here is also useful.
> > We should be able to configure our own optimization pipeline in that case, we might want the extra control as well.
> which means we basically rewrite the function `opt` and `backend` in `LTO.cpp`. I thought about just invoking backend before, especially using LTO requires us to build the resolution table. However, after a second thought, I think it would be better to just use LTO.
Building the passes isn't too complicated, it would take up the same amount of space as the symbol resolutions and has the advantage that we don't need to write the output to a file. I could write an implementation for this to see how well it works.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D139287/new/

https://reviews.llvm.org/D139287



More information about the cfe-commits mailing list