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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 16CDB3857C66 for ; Thu, 15 Apr 2021 21:51:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 16CDB3857C66 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-247-5LDZOiOOOy2BXLs2ohpPow-1; Thu, 15 Apr 2021 17:51:23 -0400 X-MC-Unique: 5LDZOiOOOy2BXLs2ohpPow-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6F7A2EC1A1; Thu, 15 Apr 2021 21:51:22 +0000 (UTC) Received: from t14s.localdomain (ovpn-112-65.phx2.redhat.com [10.3.112.65]) by smtp.corp.redhat.com (Postfix) with ESMTP id F412510016F4; Thu, 15 Apr 2021 21:51:21 +0000 (UTC) Message-ID: Subject: Re: Gcc as callable libraries (was: removing toxic emailers) From: David Malcolm To: Thomas Koenig , gcc mailing list Date: Thu, 15 Apr 2021 17:51:21 -0400 In-Reply-To: <3ae0edcddf517cf485fefd417a8785d86fa9189a.camel@redhat.com> References: <20210414131843.GA4138043@thyrsus.com> <20210414142310.98E0833DD0@vlsi1.gnat.com> <20210414152112.GD4138043@thyrsus.com> <20210415134907.GA51340@thyrsus.com> <96db05d78cb1f829d0b3ce3026ac15a335fffd41.camel@redhat.com> <8295aff7-7afb-bb9d-a102-6b106664bbf8@netcologne.de> <3ae0edcddf517cf485fefd417a8785d86fa9189a.camel@redhat.com> User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2021 21:51:27 -0000 On Thu, 2021-04-15 at 17:31 -0400, David Malcolm via Gcc wrote: > On Thu, 2021-04-15 at 21:48 +0200, Thomas Koenig wrote: [...snip...] > >  > Perhaps a pronouncement like: "try to make everything be > > consumable as > >  > libraries with APIs, as well as as standalone binaries" might > > have > >  > helped (and still could; can we do that please?) > > > > That makes perfect sense, as LLVM shows, and is something that the > > steering committee could decide for the project (or rather, it > > could > > issue a pronouncement that this will not be opposed if some > > volunteer > > does it). > > > > I think this could be as close to an unanimous decision as there > > can > > be among such a diverse community as the gcc developers.  If the > > FSF > > takes umbrage at this, the ball is in their court. > > I deliberately added the weasel-words "try to", because these things > are, of course, much easier said that done. > > I attempted to reduce gcc's use of global state back in 2013 with a > view to making it a shared library, but eventually the sheer size of > the task overwhelmed me.  In libgccjit I hid everything behind a > separate API, with a bug mutex guarding all of gcc's global state, ~~~ big, I meant to write. > which feels like something of a cop-out. libgccjit calls into as and ld, which shows up in the profile, so another idea I dabbled in the whole "libraries rather than just executables" area is to make as and ld buildable as shared libraries; hence this 2015 experiment: "[PATCH 00/16] RFC: Embedding as and ld inside gcc driver and into libgccjit" crossposted between gcc-patches and binutils here: https://gcc.gnu.org/legacy-ml/gcc-patches/2015-06/msg00116.html https://sourceware.org/legacy-ml/binutils/2015-06/msg00010.html (admittedly my prototype had a barely-existent API, but it gave me a 5x speedup on a synthetic benchmark, which was dominated by the overhead of dynamically linking libbfd into as and ld on each invocation IIRC; better to do it once when libgccjit is linked into the process). > > One idea I had would be to refactor out our diagnostics code into a > libdiagnostics (or similar), so that all of the source- > printing/underlining/fix-it logic etc could be used outside of gcc, and > the use of diagnostic_context might help towards that.  But even "just" > that's decidedly non-trivial. > > Hope this is constructive > Dave > >