Re: Converting the gcc backend to a library?

[Tim Josling <tej at melbpc dot org dot au>]

I think we could all agree in principle at least that it would be
a good thing (TM) to have a clean interface into the compiler
back end. This would be a necessary first step to having a
gcc_back_end_lib.o in any case, and well worth doing.

Here are some of the things that would need to be done:

- fix up the plethora of global variables
- move the back end code out of the various places it lives, like
in the C front end (toplev.c etc.).
- document it (by the way I have had no comments on the
translation of the german documentation I wrote at
http://www.geocities.com/timjosling - now available in very
readable HTML format. If it is a load of rubbish could someone
quietly tell me please?)

As for the idea of using RTL as an interface, the GCC manual
specifically says not to do this, although it is a frequently
suggested idea. This is because:

- not all the information is in the RTL (refer to the
aforementioned global variables for examples).
- it would be really slow. I don't know if this is true but it
sounds plausible to me.
- the basic interface into the back end is function calls, not
the RTL. And you only do it a function at a time, so you never
have all the RTL (this must make global cross function
optimization very hard).

I was actually already thinking of sending a message to this list
that perhaps we look at at moving the back end code into separate
modules, especially the stuff in toplev.c. At the moment everyone
writing a new front end has to clone backlev.c. This is probably
not too hard to fix, and should not be contentious. I could
probably do a patch to make a start on toplev.c for example.

Shared libraries can be a real pain (look at the g/libc/6 issues
with linux for example). You may want to link some things
statically.

Tim Josling

Lynn Winebarger wrote: (edited)...
>    The main purpose of such would be to allow simple text file interfacing
> with the internals of GCC.  For example, I'm working on a decompiler
> written in Scheme that uses a slightly modified RTL for an internal
> representation.  The decompiler is available under GPL.  It would be nice
> to be able to just dump the RTL (with appropriate modifications) and have
> GCC be able to read it from there.    In particular, it would help
> testing.   One could use such a feature for prototyping optimizer passes
> as well.
>    The proprietary nature of things doing the text interfacing is a
> secondary matter.
> 
> >     (2) It makes it harder for legitimate free software developers to
> >     include gcc as a library, for example, a compiler integrated into
> >     GUILE so code could be compiled on the fly.
> >
> > Reading and writing IR is *slow* and memory is cheap: linking directly with
> > GCC components or calling the entire compiler would almost certainly be the
> > better technical solution.
> >
>     My fault for confusing the two subjects as Per Bothner noted.  I don't
> think they're that far apart legally, but it's true that at least some
> (probably most or all) of the relevant steering committee people do.
> 
> >     Eventually, I'll need GCC as a library for a project I'm working on, and if
> >     it's not in the official sources, I'll have little compunction against
> >     forking my own library version because it would still be far easier to
> >     maintain that than developing my own multiplatform optimizing compiler, and
> >     the project is under GPL anyhow.
> >...
> Lynn