Re: GCC internal re-architecture proposal

[Richard Biener <richard dot guenther at gmail dot com>]

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 ...

Richard.

>
> Diego.