On Nov 17, 2007, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:

> I had no trouble getting students up to spead on well-structured
> plugable proprietary compiler within weeks.  However, the same
> experience on GCC has proven much less impressive results.
> Consequently, we have been making more progress working with
> proprietary compiler than with GCC -- something I find myself
> embarrasing :-(

That's sad, but adding to GCC the ability to support plugins (I assume
this is about dynamically-loaded GCC passes) won't change this at all.

The thing that people have historically found difficult in getting
started with GCC is that there was a lot of infrastructure that didn't
follow the patterns and algorithms found in compiler literature.  This
has changed a bit with the Tree-SSA infrastructure, not only because
SSA and GIMPLE-like representations are commonplace, but also because
there aren't as many inter-dependencies and implicit assumptions
between passes as there used to be with RTL.

But it's still true that one has to learn a lot about GCC internals
before one can write a new RTL pass, and even a new Tree-SSA pass.
Merely introducing means for people to dynamically load passes won't
change this.  Only designing a plugin API that hides a lot of GCC's
internal complexity, while still making room for useful experiments,
would make this plugin API useful to address this problem.

But then, this is much harder than just adding plugin support, and I'm
familiar with any actual proposals that would address the underlying
problem.

And then, once the underlying problem is addressed and we have an API
that is usable by regular users, maybe we will find out that we don't
need plugins, after all.  That, as Diego and Ian say, adding plugin
support is trivial, but I'm pretty sure that's not where the actual
problem lies.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}

Reply via email to