This is the mail archive of the
mailing list for the GCC project.
Re: GCC internal re-architecture proposal
- From: Diego Novillo <dnovillo at google dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Andrew MacLeod <amacleod at redhat dot com>, GCC <gcc at gcc dot gnu dot org>
- Date: Tue, 18 Mar 2014 12:34:07 -0400
- Subject: Re: GCC internal re-architecture proposal
- Authentication-results: sourceware.org; auth=none
- References: <51C470DB dot 9010203 at redhat dot com> <CAFiYyc1wECj4HS76AMntSZp8nZwkq_r35H2yjg6ZPw=hgm12jA at mail dot gmail dot com>
On Tue, Mar 18, 2014 at 10:19 AM, Richard Biener
> On Fri, Jun 21, 2013 at 5:27 PM, Andrew MacLeod <email@example.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