Re: GCC internal re-architecture proposal

[Andrew MacLeod <amacleod at redhat dot com>]

On 03/19/2014 05:08 AM, Richard Biener wrote:
> On Tue, Mar 18, 2014 at 5:34 PM, Diego Novillo <dnovillo@google.com> wrote:
> > On Tue, Mar 18, 2014 at 10:19 AM, Richard Biener
> > <richard.guenther@gmail.com> wrote:
> > > On Fri, Jun 21, 2013 at 5:27 PM, Andrew MacLeod <amacleod@redhat.com> wrote:
> > > > [ I foolishly sent this with the document as an attachment... hopefully it
> > > > gets rejected and anyone interested can simply download the document from
> > > > the wiki..]
> > > >
> > > > Over the past couple of months, I've slowly been putting together an action
> > > > plan to help modernize GCC's source base.  We've had various ideas put forth
> > > > over the years, and a few of the more meritorious ones have been
> > > > incorporated.  My primary goal is to disentangle the front end from the
> > > > middle/back ends, giving us better control over their data structures.
> > > >
> > > > The biggest challenge is having an executable plan which allows the source
> > > > to be updated incrementally.   Ie, we need a way to get from 'Here' to
> > > > 'There' that does not impact ongoing normal activities, nor noticeably
> > > > affect the performance of the compiler.  This is a huge effort and it will
> > > > require a large time commitment on my part to see it through.
> > > Sorry for following up on this old e-mail but it just occured to me that
> > > the (unfinished) GIMPLE frontend would be a great place to bootstrap
> > > the new and shiny GIMPLE data structures.
> > >
> > > Of course for it to work you need to translate that back to fat-and-old GIMPLE
> > > and eventually finish the textual format dumping as well - not sure what
> > > the state of the gimple frontend branch is.
> > Work on it stalled sometime last year.
> >
> > I'm not sure if I would mix the re-arch work with the GIMPLE FE work.
> > The parser will take the most benefit out of the new structure, but I
> > think it may be better to make the front end be a sub-branch of the
> > re-architect work so we don't conflate the two.
> >
> > Some work will be independent, but it will be easier to maintain both
> > branches if they are separate.
> >
> > I do like the idea of tying the GIMPLE front end to the re-arch
> > branch, however. So, making it a sub-branch of re-arch is definitely a
> > good idea.
> Well, I thought that the GIMPLE FE itself is the easiest place where
> you can try out things given that it has to represent all features
> of GIMPLE but doesn't (necessarily) use the GIMPLE IL as its AST.
> Especially the no-trees part should be easy there.  And we can be
> convinced of the beauty of the new AST before munging all these
> wrappers into trunk with the fear that only the wrappers will stay
> and the project itself will never finish ... thus we get the ugliness
> while with the GIMPLE FE we'd at least get the GIMPLE FE ...

Well, there are no new ASTs...The gimple IL is still the same, except 
we'll have an opportunity to better formalize it, and it will be 
statically type-safe rather than dynamic like today.  Its not really 
practical to maintain it on a branch all the way until a completely 
non-tree front end can be produced. There are too many "unrelated" 
issues to progress from where we are today to a separate front end.

That said, It has become necessary to start separating out the front end 
interface components shortly as part of the work.  This can use the 
gimple FE  as a litmus test.  Maybe we can drum up some interest and 
finish development of it.

In any case, no decisions have to be made yet, and I'm not planning to 
rush it.  I'm still refining things and it'll be a couple of months 
before its worth discussing any sort of integration plan or options.  I 
plan to put together some documentation during that time and we can 
discuss its merits and fate when that is ready.

I figure we can hash things out during the month leading up to Cauldron.

Andrew