Re: Remove support for Intel MIC offloading (was: [PATCH] Remove dead code.)

[Richard Biener via Gcc-patches]

> Am 20.10.2022 um 14:41 schrieb Jakub Jelinek via Gcc-patches 
> <gcc-patches@gcc.gnu.org>:
> 
> 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.

Might be a nice GSoC project …

Richard 

>    Jakub
>