GSoC project idea: Separate Host Process Offloading (was: Remove support for Intel MIC offloading)

2023-02-02 Thread Thomas Schwinge
Hi!

On 2023-02-01T16:12:07+0100, Martin Jambor  wrote:
> 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:
> 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.

Agreed!  Something like: "Separate Host Process Offloading"!  (Back
in October, I actually had made a TODO note to put this one onto
, but so far...)

> Would any one of those involved in this
> thread be willing to mentor it?

I'd offer to co-mentor, but I'd rather not be the only one.


I'm now off for FOSDEM, but unless someone gets it done before, I'll cook
up a GSoC project idea text when I'm back, on Tuesday.


Grüße
 Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955


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

2023-02-01 Thread Martin Jambor
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: GCC 13: OpenMP offloading to Intel MIC has been removed (was: Remove support for Intel MIC offloading)

2022-11-04 Thread Jakub Jelinek via Gcc-patches
On Fri, Nov 04, 2022 at 11:05:13AM +0100, Thomas Schwinge wrote:
> Hi!
> 
> On 2022-10-20T13:34:41+0200, Jakub Jelinek via Gcc-patches 
>  wrote:
> > we'll need to update the offloading wiki
> 
> I'll look into that.  I assume we just remove any "Intel MIC" text,
> unless historically or otherwise still relevant, of course.

Well, e.g. at the start
GCC 5 and later support two offloading configurations:

OpenMP to Intel MIC targets (upcoming Intel Xeon Phi products codenamed 
KNL) as well as MIC emulation on host. 
should be kept, and in the GCC 13 entry say that the support has been
removed.  Or perhaps better split the GCC 5 entry to say that
GCC 5 and later support OpenACC to NVidia PTX and another entry
that GCC 5 to GCC 12 support OpenMP to Intel MIC.

As there is just one wiki for all the GCC versions, I think we
should keep the MIC stuff in there for now but add notes to the various
spots that it isn't there for GCC 13 anymore (repeat the info).
And when GCC 12.5 is released and branch 12 closes we can drop it
except from the first part of the wiki.

Jakub



Re: Remove support for Intel MIC offloading

2022-11-04 Thread Thomas Schwinge
Hi Jakub!

On 2022-11-04T11:30:04+0100, Jakub Jelinek  wrote:
> On Fri, Nov 04, 2022 at 10:54:02AM +0100, Thomas Schwinge wrote:
>> On 2022-10-20T22:56:57+0200, I wrote:
>> > Hi Jakub, Tobias!
>> >
>> > On 2022-10-20T13:15:43+0200, I wrote:
>> >> I'm proposing the attached "Remove support for Intel MIC offloading"
>> >
>> > Can you please confirm:
>>
>> Taking your non-response as silent approval, I've now pushed to master
>
> I have responded in
> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603988.html

That's correct, but later I sent this other email where I asked "Can you
please confirm: [...]", which had not gotten a response.  (..., but I
convinced myself that my thinking was correct, so I now did proceed
understanding "non-response as silent approval".)


Grüße
 Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955


Re: Remove support for Intel MIC offloading

2022-11-04 Thread Jakub Jelinek via Gcc-patches
On Fri, Nov 04, 2022 at 10:54:02AM +0100, Thomas Schwinge wrote:
> Hi!
> 
> On 2022-10-20T22:56:57+0200, I wrote:
> > Hi Jakub, Tobias!
> >
> > On 2022-10-20T13:15:43+0200, I wrote:
> >> I'm proposing the attached "Remove support for Intel MIC offloading"
> >
> > Can you please confirm:
> 
> Taking your non-response as silent approval, I've now pushed to master

I have responded in
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603988.html

> branch commit e4cba49413ca429dc82f6aa2e88129ecb3fdd943
> "Remove support for Intel MIC offloading", see attached (generated with
> 'git format-patch --irreversible-delete', 'xz -9').

Jakub



GCC 13: OpenMP offloading to Intel MIC has been removed (was: Remove support for Intel MIC offloading)

2022-11-04 Thread Thomas Schwinge
Hi!

On 2022-10-20T13:34:41+0200, Jakub Jelinek via Gcc-patches 
 wrote:
> we'll need to update the offloading wiki

I'll look into that.  I assume we just remove any "Intel MIC" text,
unless historically or otherwise still relevant, of course.

Likewise I'll look through open PRs to see if any can be closed now.

And, I've pushed to wwwdocs master branch
commit c59054dae1319cd21e8198733a63d60111681d1b
"GCC 13: OpenMP offloading to Intel MIC has been removed", see attached,
borrowing both the position in the notes and wording from the GCC 12
deprecation.


Now, looking forward to the day when someone introduces support for (new)
Intel GPU offloading!  (See initial/inconclusive discussion in thread at

"GCC/OpenMP offloading for Intel GPUs?".


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From c59054dae1319cd21e8198733a63d60111681d1b Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 4 Nov 2022 10:18:38 +0100
Subject: [PATCH] GCC 13: OpenMP offloading to Intel MIC has been removed

---
 htdocs/gcc-13/changes.html | 1 +
 1 file changed, 1 insertion(+)

diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index f5fa97e5..8b4bf7f3 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -28,6 +28,7 @@ a work-in-progress.
 
 Caveats
 
+OpenMP offloading to Intel MIC has been removed.
 The support for the cr16-elf, tilegx*-linux, tilepro*-linux,
   hppa[12]*-*-hpux10*, hppa[12]*-*-hpux11*
   and m32c-rtems configurations has been removed.
-- 
2.35.1



Remove support for Intel MIC offloading

2022-11-04 Thread Thomas Schwinge
Hi!

On 2022-10-20T22:56:57+0200, I wrote:
> Hi Jakub, Tobias!
>
> On 2022-10-20T13:15:43+0200, I wrote:
>> I'm proposing the attached "Remove support for Intel MIC offloading"
>
> Can you please confirm:

Taking your non-response as silent approval, I've now pushed to master
branch commit e4cba49413ca429dc82f6aa2e88129ecb3fdd943
"Remove support for Intel MIC offloading", see attached (generated with
'git format-patch --irreversible-delete', 'xz -9').


Grüße
 Thomas


>> --- a/gcc/config/i386/i386-options.cc
>> +++ b/gcc/config/i386/i386-options.cc
>> @@ -307,10 +307,6 @@ ix86_omp_device_kind_arch_isa (enum 
>> omp_device_kind_arch_isa trait,
>>  case omp_device_kind:
>>return strcmp (name, "cpu") == 0;
>>  case omp_device_arch:
>> -#ifdef ACCEL_COMPILER
>> -  if (strcmp (name, "intel_mic") == 0)
>> - return 1;
>> -#endif
>>if (strcmp (name, "x86") == 0)
>>   return 1;
>>if (TARGET_64BIT)
>
> Only remove this bit as quoted, or actually remove the whole function
> (used for 'gcc/config/i386/i386.cc:TARGET_OMP_DEVICE_KIND_ARCH_ISA')?
> But if I do the latter, I get a few FAILs in compiler-side
> '[...]/gomp/declare-variant-[...]' test cases, and
> 'libgomp.c/declare-variant-1.c'.
>
> You, Jakub, had originally added that in
> Subversion r277662 (Git commit 9ba66bf5b9c69e0e2bcd1b2ab88160bf9b2aa417)
> "targetm.omp.device_kind_arch_isa and OpenMP declare variant kind/arch/isa 
> handling".
> Reading these emails, and the discussion in
> <https://gcc.gnu.org/PR105640>
> "[OpenMP] Context selectors missing for PowerPC", I infer that we
> generally would like to keep this stuff, for non-offloading OpenMP use,
> and thus indeed just remove the Intel MIC parts (as quoted above).
>
> Thus:
>
>> --- a/libgomp/libgomp.texi
>> +++ b/libgomp/libgomp.texi
>> @@ -4303,10 +4303,6 @@ offloading devices (it's not clear if they should be):
>>
>>  @multitable @columnfractions .60 .10 .25
>>  @headitem @code{arch} @tab @code{kind} @tab @code{isa}
>> -@item @code{intel_mic}, @code{x86}, @code{x86_64}, @code{i386}, @code{i486},
>> -  @code{i586}, @code{i686}, @code{ia32}
>> -  @tab @code{host}
>> -  @tab See @code{-m...} flags in ``x86 Options'' (without @code{-m})
>>  @item @code{amdgcn}, @code{gcn}
>>@tab @code{gpu}
>>@tab See @code{-march=} in ``AMD GCN Options''
>
> ..., I should also restore this, and only remove the Intel MIC mention.
>
> On the other hand:
>
>> diff --git a/gcc/config/i386/t-omp-device b/gcc/config/i386/t-omp-device
>> deleted file mode 100644
> | index cfb41ed71ce..000
> | --- gcc/config/i386/t-omp-device
> | +++ /dev/null
> | @@ -1,6 +0,0 @@
> | -omp-device-properties-i386: $(srcdir)/config/i386/i386-options.cc
> | - echo kind: cpu > $@
> | - echo arch: intel_mic x86 x86_64 i386 i486 i586 i686 ia32 >> $@
> | - echo isa: sse4 `sed -n '/^static struct ix86_target_opts 
> isa2\?_opts\[\] =/,/^};/p' \
> | -   $(srcdir)/config/i386/i386-options.cc | \
> | -   sed -n 's/",.*$$//;s/^  { "-m//p'` >> $@
>
> Indeed remove this whole file, or just Intel MIC, again?  Here, as I
> understand, this is fine to remove completely, as is only used if there
> is an actual offload compiler (which now there isn't anymore); unused as
> of here:
>
>> --- a/gcc/configure.ac
>> +++ b/gcc/configure.ac
>
>> @@ -1153,10 +1147,6 @@ for tgt in `echo $enable_offload_targets | sed 's/,/ 
>> /g'`; do
>>
>>enable_offloading=1
>>case "$tgt" in
>> -*-intelmic-* | *-intelmicemul-*)
>> - omp_device_property=omp-device-properties-i386
>> - omp_device_property_tmake_file="${omp_device_property_tmake_file} 
>> \$(srcdir)/config/i386/t-omp-device"
>> - ;;
>>  amdgcn*)
>>   omp_device_property=omp-device-properties-gcn
>>   omp_device_property_tmake_file="${omp_device_property_tmake_file} 
>> \$(srcdir)/config/gcn/t-omp-device"
>
> So I assume that is OK the way I had it prepared.
>
>
> Grüße
>  Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955


0001-Remove-support-for-Intel-MIC-offloading.patch.xz
Description: application/xz


Re: Remove support for Intel MIC offloading

2022-10-20 Thread Thomas Schwinge
Hi Jakub, Tobias!

On 2022-10-20T13:15:43+0200, I wrote:
> I'm proposing the attached "Remove support for Intel MIC offloading"

Can you please confirm:

> --- a/gcc/config/i386/i386-options.cc
> +++ b/gcc/config/i386/i386-options.cc
> @@ -307,10 +307,6 @@ ix86_omp_device_kind_arch_isa (enum 
> omp_device_kind_arch_isa trait,
>  case omp_device_kind:
>return strcmp (name, "cpu") == 0;
>  case omp_device_arch:
> -#ifdef ACCEL_COMPILER
> -  if (strcmp (name, "intel_mic") == 0)
> - return 1;
> -#endif
>if (strcmp (name, "x86") == 0)
>   return 1;
>if (TARGET_64BIT)

Only remove this bit as quoted, or actually remove the whole function
(used for 'gcc/config/i386/i386.cc:TARGET_OMP_DEVICE_KIND_ARCH_ISA')?
But if I do the latter, I get a few FAILs in compiler-side
'[...]/gomp/declare-variant-[...]' test cases, and
'libgomp.c/declare-variant-1.c'.

You, Jakub, had originally added that in
Subversion r277662 (Git commit 9ba66bf5b9c69e0e2bcd1b2ab88160bf9b2aa417)
"targetm.omp.device_kind_arch_isa and OpenMP declare variant kind/arch/isa 
handling".
Reading these emails, and the discussion in
<https://gcc.gnu.org/PR105640>
"[OpenMP] Context selectors missing for PowerPC", I infer that we
generally would like to keep this stuff, for non-offloading OpenMP use,
and thus indeed just remove the Intel MIC parts (as quoted above).

Thus:

> --- a/libgomp/libgomp.texi
> +++ b/libgomp/libgomp.texi
> @@ -4303,10 +4303,6 @@ offloading devices (it's not clear if they should be):
>
>  @multitable @columnfractions .60 .10 .25
>  @headitem @code{arch} @tab @code{kind} @tab @code{isa}
> -@item @code{intel_mic}, @code{x86}, @code{x86_64}, @code{i386}, @code{i486},
> -  @code{i586}, @code{i686}, @code{ia32}
> -  @tab @code{host}
> -  @tab See @code{-m...} flags in ``x86 Options'' (without @code{-m})
>  @item @code{amdgcn}, @code{gcn}
>@tab @code{gpu}
>@tab See @code{-march=} in ``AMD GCN Options''

..., I should also restore this, and only remove the Intel MIC mention.

On the other hand:

> diff --git a/gcc/config/i386/t-omp-device b/gcc/config/i386/t-omp-device
> deleted file mode 100644
| index cfb41ed71ce..000
| --- gcc/config/i386/t-omp-device
| +++ /dev/null
| @@ -1,6 +0,0 @@
| -omp-device-properties-i386: $(srcdir)/config/i386/i386-options.cc
| - echo kind: cpu > $@
| - echo arch: intel_mic x86 x86_64 i386 i486 i586 i686 ia32 >> $@
| - echo isa: sse4 `sed -n '/^static struct ix86_target_opts 
isa2\?_opts\[\] =/,/^};/p' \
| -   $(srcdir)/config/i386/i386-options.cc | \
| -   sed -n 's/",.*$$//;s/^  { "-m//p'` >> $@

Indeed remove this whole file, or just Intel MIC, again?  Here, as I
understand, this is fine to remove completely, as is only used if there
is an actual offload compiler (which now there isn't anymore); unused as
of here:

> --- a/gcc/configure.ac
> +++ b/gcc/configure.ac

> @@ -1153,10 +1147,6 @@ for tgt in `echo $enable_offload_targets | sed 's/,/ 
> /g'`; do
>
>enable_offloading=1
>case "$tgt" in
> -*-intelmic-* | *-intelmicemul-*)
> - omp_device_property=omp-device-properties-i386
> - omp_device_property_tmake_file="${omp_device_property_tmake_file} 
> \$(srcdir)/config/i386/t-omp-device"
> - ;;
>  amdgcn*)
>   omp_device_property=omp-device-properties-gcn
>   omp_device_property_tmake_file="${omp_device_property_tmake_file} 
> \$(srcdir)/config/gcn/t-omp-device"

So I assume that is OK the way I had it prepared.


Grüße
 Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955


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

2022-10-20 Thread Richard Biener via Gcc-patches



> 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.)

2022-10-20 Thread 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.

Jakub



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

2022-10-20 Thread Michael Matz via Gcc-patches
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.)

2022-10-20 Thread Jakub Jelinek via Gcc-patches
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



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

2022-10-20 Thread Thomas Schwinge
Hi!

On 2021-11-12T06:41:41-0800, "H.J. Lu via Gcc-patches" 
 wrote:
> On Fri, Nov 12, 2021 at 6:27 AM Martin Liška  wrote:
>> On 11/8/21 15:19, Jeff Law wrote:
>> > On 11/8/2021 2:59 AM, Jakub Jelinek via Gcc-patches wrote:
>> >> liboffloadmic is copied from upstream [...]
>> >> But I have no idea where it even lives upstream.
>> > I thought MIC as an architecture was dead, so it could well be the case 
>> > that there isn't a viable upstream anymore for that code.
>>
>> @H.J. ?
>
> We'd like to deprecate MIC offload in GCC 12.

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 (like LLVM a while ago
implemented), and so on), but all that doesn't help -- in practice -- if
nobody is maintaining that code.  Also, currently that (very "bulky")
code is buildable for x86/x86_64 GNU/Linux only (again for no particular
reason, as far as I can tell).

> We will remove all traces of
> MIC offload in GCC 13.

This had come up again at the GNU Tools Cauldron 2022 (relevant folks
CCed), and I had been tasked to execute that.  Explicitly note that this
does not bear any relationship with our ongoing work to support
offloading to AMD and Nvidia GPUs: the more, the merrier, as far as I'm
concerned, and actually I had been testing Intel MIC (emulated)
offloading until a few days ago.  (Also, I had been curious about support
for Intel GPUs --
<https://inbox.sourceware.org/gcc/87v933nlhn@dem-tschwing-1.ger.mentorg.com/>
"GCC/OpenMP offloading for Intel GPUs?" -- but Intel don't seem
interested in working on that themselves?)

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).


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From cedd4fa1ad2ee78355d75b30696669716cc9546e Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 17 Oct 2022 22:19:55 +0200
Subject: [PATCH] Remove support for Intel MIC offloading

---
 Makefile.def  | 8 -
 Makefile.in   |   520 +-
 configure |66 +-
 configure.ac  |57 +-
 contrib/gcc-changelog/git_commit.py   | 1 -
 contrib/gcc_update| 6 -
 contrib/update-copyright.py   | 1 -
 gcc/config.gcc| 8 -
 gcc/config/i386/i386-options.cc   | 4 -
 gcc/config/i386/intelmic-mkoffload.cc |   728 -
 gcc/config/i386/intelmic-offload.h|35 -
 gcc/config/i386/t-intelmic|10 -
 gcc/config/i386/t-omp-device  | 6 -
 gcc/configure |14 +-
 gcc/configure.ac  |10 -
 gcc/doc/install.texi  | 2 +-
 gcc/doc/sourcebuild.texi  | 3 -
 include/gomp-constants.h  | 3 +-
 libgomp/configure | 3 -
 libgomp/libgomp-plugin.h  | 1 -
 libgomp/libgomp.texi  | 4 -
 libgomp/plugin/configfrag.ac  | 3 -
 libgomp/testsuite/lib/libgomp.exp |37 -
 .../libgomp.c-c++-common/on_device_arch.h |35 -
 .../libgomp.c-c++-common/target-45.c  | 2 -
 .../testsuite/libgomp.fortran/target10.f90| 1 -
 liboffloadmic/ChangeLog   |   765 -
 liboffloadmic/Makefile.am |   160 -
 liboffloadmic/Makefile.in |  1310 --
 liboffloadmic/aclocal.m4  |  1180 --
 liboffloadmic/configure   | 17512 
 liboffloadmic/configure.ac|   143 -
 liboffloadmic/configure.tgt   |39 -
 liboffloadmic/doc/doxygen/config  |  2328 --
 liboffloadmic/doc/doxygen/header.tex  |90 -
 .../include/coi/common/COIEngine_common.h |   121 -
 .../include/coi/common/COIEvent_common.h  |84 -
 .../include/coi/common/COIMacros_common.h |   229 -
 .../include/coi/common/COIPerf_common.h   |87 -
 .../include/coi/common/COIResult_common.h |