Re: Remove support for Intel MIC offloading (was: [PATCH] Remove dead code.)
Hello, On Thu, Oct 20 2022, Richard Biener via Gcc-patches wrote: >> Am 20.10.2022 um 14:41 schrieb Jakub Jelinek via Gcc-patches >> : >> >> On Thu, Oct 20, 2022 at 12:33:28PM +, 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 … > I really think it could be. Would any one of those involved in this thread be willing to mentor it? Thanks, Martin
Re: Remove support for Intel MIC offloading (was: [PATCH] Remove dead code.)
> Am 20.10.2022 um 14:41 schrieb Jakub Jelinek via Gcc-patches > : > > On Thu, Oct 20, 2022 at 12:33:28PM +, 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 >
Re: Remove support for Intel MIC offloading (was: [PATCH] Remove dead code.)
On Thu, Oct 20, 2022 at 12:33:28PM +, 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
Re: Remove support for Intel MIC offloading (was: [PATCH] Remove dead code.)
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. Ciao, Michael.
Re: Remove support for Intel MIC offloading (was: [PATCH] Remove dead code.)
On Thu, Oct 20, 2022 at 01:15:43PM +0200, Thomas Schwinge wrote: > I'm proposing the attached "Remove support for Intel MIC offloading" > (generated with 'git format-patch --irreversible-delete', and 'diff's for > regenerated files manually snipped, to reduce its size). ChangeLog missing, you'll need one for a successful commit. Otherwise LGTM. But we'll need to update the offloading wiki too. Jakub
