Re: LTO and adding extra information from extra passes

[Diego Novillo <dnovillo at google dot com>]

On Wed, Sep 2, 2009 at 16:06, Basile
STARYNKEVITCH<basile@starynkevitch.net> wrote:
> Hello All,
>
> My feeling is that the Link Time Optimisation (LTO) effort should be soon
> (=is expected to be, or is already) merged inside GCC trunk (future 4.5).
>
> Several years ago, I asked if there is any possibility for an additional
> pass to profit of LTO infrastructure to add some extra data into LTO stuff
> (which is probably DWARF related inside ELF object files, but I am not sure)
> and to retrieve it. I remember that the answer was of course not.

Note that the gimple streamer does not use dwarf encoding.  It uses
its own bytecode format.  There is no dwarf in the ELF files, unless
you use -g.

> Now we have a working plugin infrastructure, and I believe it would be very
> sensible for some plugin to register passes which add persistent information
> (as does LTO with its Gimple related representation) into object files and
> to retrieve it.

Yes.  That's been my plan all along.  Once LTO is merged in trunk, we
should add some plugin events to allow interaction with the streamer
as it writes and reads the callgraph.

> Even the mere ability to add inside the LTO data a chunk of bytes identified
> by the name of the plugin would be great. Of course, some more features
> could be welcome (e.g. the ability to add data specific to each compiled
> function or cgraph_node or whatever, or even to each gimple...).

Passes can add their own data to the bytecode.  A couple of IPA passes
are already doing that in the branch (notably, the inliner).

> A dream case example would be a plugin for whole program static analysis.

Note that gimple may not be an appropriate IL to do some kinds of
static analysis.  In gimple we have lost many front end attributes
that a static analyzer may want to use.  However, combined with -g,
this could be partially reconstructed.

Regardless, I agree that there are some analyses that are still
possible and useful that can be done right after the compiler has
built the complete callgraph.


Diego.