gcc : c++11 : full support : eta?

[Diego Novillo]

On Thu, Jan 24, 2013 at 1:08 PM, Jeff Law <law@redhat.com> wrote:
> On 01/24/2013 10:23 AM, Alexandre Oliva wrote:
>>
>> On Jan 23, 2013, Aldy Hernandez <aldyh@redhat.com> wrote:
>>
>>> an internal training program Jeff Law devised over a decade ago (*)
>>
>>
>>> [Before anybody asks, the training program is probably no longer
>>> relevant.  So no fair bugging Jeff about it :)].
>>
>>
>> Yeah.  It was focused on the RTL/md part of GCC, with a few simple
>> assignments that amounted to implementing changes in the mn10300-elf
>> port.  That was before AM33/2.0 came up; before gimple and SSA, long
>> before tuples and mode iterators.  GCC was a very different beast then.
>> The course made me more of an RTL person, which still makes me hope this
>> tree-based stuff a fad and that some day we'll get back to our senses
>> and do SSA in RTL ;-)
>
> And the thing to remember about that training program is that it was geared
> strictly towards backend porting.  ie, new version of the frob chip comes
> out with some new instructions, we need to support them. That was a
> significant component of Cygnus's business back then.
>
> As Alex notes, GCC today is dramatically different and hacking new
> instructions into existing backends isn't nearly as important as it was 10+
> years ago.   Training around GCC's implementation of SSA, how GCC's
> optimization pipeline works, plugins, the propagation engine would be far
> more interesting and useful.
>
> When we made the change from RTL centric to gimple, one of the goals was to
> make GCC more approachable.  I would argue to some degree that was
> successful, but not nearly as much as I'd hoped.
>
> Of course that was over 10 years ago and we're at another point where some
> significant architectural changes to GCC are needed.  Google has kicked some
> stuff around and Red Hat is kicking stuff around toward that goal.
>
> I believe the ultimate focus will be on improving modularity for passes
> prior to gimple->rtl expansion and to make any notable progress we're going
> to have to tackle the type system problems.  It won't be sexy or fun, but to
> keep GCC relevant, it's one of the things we need to tackle.

Agreed.

I do see, however, a few areas where Clang/LLVM have gone that I do
not think GCC is currently thinking of entering: "toolability" (for
the lack of a better term).  Clang's design follows a different path
than g++.  It's not just a code generating parser, it is a pure parser
that also generates code.  The difference makes it suitable for any
kind of tool that needs to understand C++: static analyzers, code
re-formatters, syntax highlighters, and other similar tools.
Additionally, it is designed as a library, so it can be embedded into
applications.

That is a need that g++ cannot currently satisfy.  With plugins, one
could do something along those lines, but they are heavier, and are at
the mercy of the full compiler.  Additionally, g++ has very low
fidelity wrt the input program; it breaks down the original C++ input
almost immediately.

That is not necessarily a bad thing for g++.  But, to effectively
compete in those areas, it will need to be significantly re-organized.

LLVM has similar properties, at least as far as the middle end of the
compiler is concerned.  GCC still has an edge wrt backend portability.


Diego.