From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id D34A438515C3 for ; Thu, 20 Oct 2022 12:41:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D34A438515C3 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666269661; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=rkg4IWPT6x2Dct7HYoYToh1RY3hVyf6tIqCtoFie9Z8=; b=gQ/bDWy3554Kt4LEuoXBlgYgd2S7UdaFD4GvTbWe3YOrBZTnzYYjB5jeAErgkDMC/q875P 0OKnwI0X1Gz/0h7RoVGK1RC139TlXDQvfRE+0xFDy/BJgAelJ4miu3xWjfAtkrXvQZf3N9 +PGxO1xBxOp1xDOkhh0lkFacIS7wYwE= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-652-MKRKOtqaO2uYorspsAw-1Q-1; Thu, 20 Oct 2022 08:40:57 -0400 X-MC-Unique: MKRKOtqaO2uYorspsAw-1Q-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 016DB3C0D1A1; Thu, 20 Oct 2022 12:40:57 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.193.252]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6BFAE1415113; Thu, 20 Oct 2022 12:40:56 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 29KCeq8u1621502 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 20 Oct 2022 14:40:53 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 29KCeo751621501; Thu, 20 Oct 2022 14:40:50 +0200 Date: Thu, 20 Oct 2022 14:40:50 +0200 From: Jakub Jelinek To: Michael Matz Cc: Thomas Schwinge , "H.J. Lu" , Hongtao Liu , gcc-patches@gcc.gnu.org, Martin =?utf-8?B?TGnFoWth?= , Tobias Burnus , Richard Biener Subject: Re: Remove support for Intel MIC offloading (was: [PATCH] Remove dead code.) Message-ID: Reply-To: Jakub Jelinek References: <499b9ae2-1365-a954-ed5e-35aede5d0def@suse.cz> <20211108085918.GH2710@tucnak> <3376e0dd-9f8e-ebac-eaef-4f02865807c3@suse.cz> <87a65qhhk0.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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: 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. Jakub