From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by sourceware.org (Postfix) with ESMTPS id 78477386076B for ; Thu, 20 Oct 2022 13:09:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 78477386076B Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de 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 B52C122589; Thu, 20 Oct 2022 13:09:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1666271370; 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=mO0XUvgeOBAfz3EKyi/VuwF3MocLrM+WOq1oRyyM4w4=; b=HhLy6WEQ/Fx5wguKrSa5JgPeMTzlEDaNwvrTT+NCDQVQ3xGr/lpusBziz0cDnZ8+vbWqkz XsCwp6r5oNybVhMmwnK7FD9HBFsaNdAQSIEuco0dCwpv8OaGfbvaxfX7C8foBY7szT/+p2 GXKD2h3Q+5aH+COfFeuiXp3hDJ0TUPY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1666271370; 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=mO0XUvgeOBAfz3EKyi/VuwF3MocLrM+WOq1oRyyM4w4=; b=38OtaeQmN1LTzI5by7Xqs9iRvhZLCWomtx9Fk5silr9boMRG3dV/zKS0+mj23fao5VIzg4 eP0SXnOpt5OEZYAA== 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 944D813AF5; Thu, 20 Oct 2022 13:09:30 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id c71mJIpIUWPDOgAAMHmgww (envelope-from ); Thu, 20 Oct 2022 13:09:30 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Richard Biener Mime-Version: 1.0 (1.0) Subject: Re: Remove support for Intel MIC offloading (was: [PATCH] Remove dead code.) Date: Thu, 20 Oct 2022 15:09:29 +0200 Message-Id: References: Cc: Michael Matz , gcc-patches@gcc.gnu.org, Tobias Burnus , Hongtao Liu , Thomas Schwinge In-Reply-To: To: Jakub Jelinek X-Mailer: iPhone Mail (19H12) X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_LOW,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: > 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 useful= >>> for offloading simulation/debugging (separate host/device memory spaces,= >>> 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 transformed= =20 >> into a "null"-offload target, as example and testing vehicle (and implyin= g=20 >> that such new liboffloadmic^H^H^Hnull would have its upstream in the GCC=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 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 =E2=80=A6 Richard=20 > Jakub >=20