On Mon, 2013-07-29 at 11:19 +0100, Richard Earnshaw wrote:
> On 26/07/13 16:04, David Malcolm wrote:
> > The following patch series eliminates the mutable global variables
> > representing GCC's passes, allowing for multiple compilation contexts in
> > one process, potentially with different combinations of passes
> > (e.g. JIT-compilation of JavaScript in one thread, JIT-compilation
> > of OpenGL shader programs in another) and with pass instances owning
> > additional data, including GC references.
> >
> > The opt_pass hierarchy becomes a true C++ class hierarchy.
> >
> > Patch 1 introduces a gcc::pipeline class and moves various non-GTY
> > globals relating to pass management into it. The gcc::context gains its
> > first field: a pointer to the gcc::pipeline instance.
> >
>
> Why 'pipeline'? Given that we already use the term for hardware
> scheduling, it seems particularly confusing to use that term here for
> something that seems to be completely unrelated.
How about "gcc::pass_manager"? (retaining "passes" as the typical name
for instances, for brevity), so we'd have this method within
gcc::context:
pass_manager& get_passes () { gcc_assert (passes_); return *passes_; }
and pipeline.h would become pass_manager.h
(and probably with a "using gcc::pass_manager;" to avoid spelling out
the namespace everywhere).
