On Thu, Oct 20, 2022 at 12:33:28PM +0000, Michael Matz wrote:
> Hey,
>
> On Thu, 20 Oct 2022, Thomas Schwinge wrote:
>
> > This had been done in
> > wwwdocs commit 5c7ecfb5627e412a3d142d8dc212f4cd39b3b73f
> > "Document deprecation of OpenMP MIC offloading in GCC 12".
> >
> > I'm sad about this, because -- in theory -- such a plugin is very useful
> > for offloading simulation/debugging (separate host/device memory spaces,
> > allow sanitizers to run on offloaded code
>
> Yeah, I think that's a _very_ useful feature, but indeed ...
>
> > (like LLVM a while ago
> > implemented), and so on), but all that doesn't help -- in practice -- if
> > nobody is maintaining that code.
>
> ... it should then be somewhat maintained properly. Maybe the
> MIC-specifics could be removed from the code, and it could be transformed
> into a "null"-offload target, as example and testing vehicle (and implying
> that such new liboffloadmic^H^H^Hnull would have its upstream in the GCC
> repo). Alas, if noone is going to do that work removing is the right
> choice.
Yeah. But we really shouldn't need a large MIC specific library for that,
everything should be implementable with a simple portable plugin that just
forks + execs the offloading ELF and transfers data to/out of it etc.
And the config/i386/intelmic-mkoffload etc. stuff would need to be done
somewhere in generic code, such that we can do it for all targets.
Also ideally by using just the normal lto1 with some special option that
it acts as an offloading compiler, so that we don't need to bother with
building a separate offloading compiler for it.
True, everything guarded with #ifdef ACCEL_COMPILER etc. would need to
change into code guarded with some option.
Jakub
