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