This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC internal re-architecture proposal

On Tue, Mar 18, 2014 at 10:19 AM, Richard Biener
<> wrote:
> On Fri, Jun 21, 2013 at 5:27 PM, Andrew MacLeod <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]