Re: GCC IMA & general future proposal

[Jan Hubicka <jh at suse dot cz>]

> Jan Hubicka wrote:
> >>Jan Hubicka wrote:
> >>
> >>
> >>>>It is still useful in such a framework for front ends to be able to
> >>>>handle multiple translation units at once as C does, and pass off
> >>>>GENERIC for all
> >>>>of them to the next level at once, so that various
> >>>>cross-translation-unit consistency checks can be made which depend
> >>>>on language-specific rules.
> >>>
> >>>Also for C++ you don't need to end up with duplicated template bodies
> >>>everywhere.
> >>
> >>This is going to be complex though. If you look at the EDG frontend, they 
> >>use
> >>an iterative system to generate the minimum set of template 
> >>instantiations (at
> >>least, by default):
> >>
> >>- When a file is first compiled, no templates are instantiated. Instead, a
> >>separate text file (.ti IIRC) is generated with a list of the 
> >>instantiations
> >>that the file requires.
> >>- At link time, all these files are collected and merged, getting an 
> >>unique
> >>lists of all the template instantiations needed.
> >>- A new set of text files (.to IIRC) is generated, which contains the 
> >>list of
> >>instantiations which are requested for each file.
> >>- The files with a .to list are recompiled. The presence of the .to file
> >>automatically triggers the requested template instantiations. The .ti 
> >>file is
> >>generated again: it can be a superset of the previous one because the 
> >>requested
> >>instantiations might generate new dependencies on missing instantiations.
> >>- The process is re-iterated: the .ti files are merged again, and if 
> >>there are
> >>missing instantiations, new .to files are generated, and so on.
> >>
> >>Of course, special care must be taken at link time when assigning
> >>instantiations to files, to avoid endless loops, and minimize 
> >>recompilations.
> >>EDG used to have bugs like this which are very hard to reduce and 
> >>reproduce.
> >>
> >>An additional good point of this system is that it is kind of "stable": 
> >>if you
> >>modify a single file, assuming you don't ask for more instantiations, you 
> >>do
> >>not have to recompile anything when you link. My experience is that 
> >>building
> >>big applications from scratch might requires several instantiation loops 
> >>(up to
> >>3 in my applications), but after that the compilation times after 
> >>touching a
> >>small set of files is much decreased.
> >>
> >>I think that such a system could be added to GCC as well, by using a new 
> >>option
> >>(-fcool-template-processing) and a special collect2-like program to be 
> >>run at
> >>link time.
> >>
> >>In other words, I believe a solution to the problem of minimizing the 
> >>template
> >>instantiations is orthogonal to IMA and its design.
> >
> >
> >I've had someting easier in my mind here - you simply parse multiple C++
> >files to memory like we can do now for C and then do template
> >instantiation same way we are doing now but taking into acount that you
> >don't need to instantiate same template multiple times for different
> >files.
> >
> >Of course something that scales to bigger units better than this "easy"
> >trick is desirable.  The way EDG does this looks pretty amusing to me ;))
> >I wonder if they do have some paper or something with experimental
> >results of this approach (ie how often the reduction in templates
> >outweight the recompilation costs)
> 
> This may be a stupid suggestion and is probably not as general
> as what EDG is doing but couldn't the template instantiations be
> put into special sections and then let ld eliminate the duplicates
> as it merges the object files into the executable?

This is what GCC does currently, but it results in very many
instantiations being compiled just to be thrown away that consumes time
and disc space.

Honza
> 
> >Honza
> >
> >>Giovanni Bajo
> >>
> >>
> 
> 
> -- 
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel@OARcorp.com                 On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>    Support Available             (256) 722-9985
>