From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id BF4F93858D33 for ; Wed, 1 Feb 2023 15:12:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BF4F93858D33 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.cz Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id C6096336FE; Wed, 1 Feb 2023 15:12:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1675264327; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nhanH1KrTGSpVKP6b/U+YMKX5vnbfYdtychZU0CUa0o=; b=zF10LNVGIRMAboGKa+XkPjqgGgLq0qEUkrV6yrnWf1RxMvfK13mN/mg7k92lYQLrQubNPn 59QnKfucO8M6JEQKNlDg3DicdU+kCVbZwnDgM+bO117s2B5OLO7RRcEBMsXcTBjZNcatWw OmGKfPK9L4aqKSSDnJQ8E14S/E6hnag= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1675264327; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nhanH1KrTGSpVKP6b/U+YMKX5vnbfYdtychZU0CUa0o=; b=80sn1+SF/o2JSOVpcP3dfWy2n15IpuEcuDm5CIKTbSYZC80CpbtsEBpOtFRBlO+p6eN2IM VQC114U9no0NY6Aw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id B61A913A10; Wed, 1 Feb 2023 15:12:07 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id NiRCLEeB2mMwDAAAMHmgww (envelope-from ); Wed, 01 Feb 2023 15:12:07 +0000 From: Martin Jambor To: Richard Biener , Jakub Jelinek Cc: Tobias Burnus , Hongtao Liu , Michael Matz , gcc-patches@gcc.gnu.org, Thomas Schwinge Subject: Re: Remove support for Intel MIC offloading (was: [PATCH] Remove dead code.) In-Reply-To: References: User-Agent: Notmuch/0.37 (https://notmuchmail.org) Emacs/28.2 (x86_64-suse-linux-gnu) Date: Wed, 01 Feb 2023 16:12:07 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 : >>=20 >> =EF=BB=BFOn Thu, Oct 20, 2022 at 12:33:28PM +0000, Michael Matz wrote: >>> Hey, >>>=20 >>>> On Thu, 20 Oct 2022, Thomas Schwinge wrote: >>>>=20 >>>> This had been done in >>>> wwwdocs commit 5c7ecfb5627e412a3d142d8dc212f4cd39b3b73f >>>> "Document deprecation of OpenMP MIC offloading in GCC 12". >>>>=20 >>>> I'm sad about this, because -- in theory -- such a plugin is very usef= ul >>>> for offloading simulation/debugging (separate host/device memory space= s, >>>> allow sanitizers to run on offloaded code >>>=20 >>> Yeah, I think that's a _very_ useful feature, but indeed ... >>>=20 >>>> (like LLVM a while ago >>>> implemented), and so on), but all that doesn't help -- in practice -- = if >>>> nobody is maintaining that code. >>>=20 >>> ... it should then be somewhat maintained properly. Maybe the=20 >>> MIC-specifics could be removed from the code, and it could be transform= ed=20 >>> into a "null"-offload target, as example and testing vehicle (and imply= ing=20 >>> that such new liboffloadmic^H^H^Hnull would have its upstream in the GC= C=20 >>> repo). Alas, if noone is going to do that work removing is the right=20 >>> choice. >>=20 >> Yeah. But we really shouldn't need a large MIC specific library for tha= t, >> everything should be implementable with a simple portable plugin that ju= st >> 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 =E2=80=A6 > I really think it could be. Would any one of those involved in this thread be willing to mentor it? Thanks, Martin