This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Converting the gcc backend to a library?
"Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de> writes:
> > > So it would seem the only issue is whether the bulk of GCC could be linked as
> > > a shared library. But that seems marginal on both sides: most machines are
> > > single-user nowadays and memory is cheap, so the benefit of having it as
> > > a shared library is trivial (the number of times the use count of such an
> > > image would be greater than one is negligable)
> >
> > Not so. Consider a dynamic compilation environment such as Java, Guile,
> > Perl or even Emacs Lisp if such things were that easy. Every
> > interpreter-come-compiler uses an instance of the shared library.
>
> And then, the compiler backend generates assembly code. Ok, so you
> link in the assembler and the linker as well. That produces an object
> file, which you'll have to load via dlopen. I don't think anybody with
> an understanding of the issues would consider such a technology for
> JIT...
>
> I think even if gcc *was* a shared library, we would be still *years*
> away from a dynamic compilation environment.
Yes, and no.
GCC is an optimizing compiler, not what you want on the first pass in
dynamic compilation environment.
However. A fairly optimal approach is to build a byte code compiler
(or something similiarly fast, and nonoptimizing). Get call trace,
and common case analysis from that code. And then in when code
gets hit enough send out to gcc for an optimized version load.
That said the shared library approach still has merit, as you want to
look at reducing the cost of your optimizing compile.
As to years away(What kind of years?). I agree we are some distance,
but all of the basic pieces and techniques exits. It just requires
someone to put the together.
Eric