On Thu, Jan 24, 2013 at 1:08 PM, Jeff Law <l...@redhat.com> wrote: > On 01/24/2013 10:23 AM, Alexandre Oliva wrote: >> >> On Jan 23, 2013, Aldy Hernandez <al...@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.
