Kenneth Zadeck <[EMAIL PROTECTED]> writes: > I think that one thing that the gcc community should understand is > that to a great extent whopr is a google thing. All of the documents > are drafted by google people, in meetings that are only open to google > people and it is only after these documents have been drafted do the > people who are outside of google who are working on lto, like Honza > and myself, see the documents and get to comment. The gcc community > never sees the constraints, deadlines, needs, or benchmarks that are > motivating the decisions that are made in the whopr documents.
Every new gcc development starts that way. Somebody has to put together the initial proposal. How many people were invited to work on the initial LTO proposal before it was sent out? Did anybody outside of Red Hat see the tree-ssa proposal before it was sent out? The WHOPR document has been out there for some time, and it was sent out before any implementation work started. There is no Google cabal pushing it. There is no secret information behind it, no constraints or deadlines or benchmarks. We did have the advantage of talking to Google employees about their experience with LTO-style work done at Intel and HP and Transmeta. Some of the people we talked to have no plans or interest in working on gcc, and it would not be fair to rope them into the conversation further. Google's needs are clear: we have large programs. Let's deal with these issues on the technical merits, not on organizational issues. If Google were dumping code on gcc, you would have a legitimate complaint. Here Google is proposing plans before any work is started. You seem to be complaining that the community should have seen the plans at an earlier stage. That makes no sense. They are still just plans, they were based on all of two days of meetings and discussions, and they are still completely open to discussion and change. > Honza and I plan, and are implementing, a system where most, but > probably all of the ipa passes, will be able to work in an environment > where the entire call graph and all of the decls and types are > available. I.e. only the function bodies are missing. In this > environment, we plan to do all of the interprocedural analysis and > generate work orders that will be applied to each function. I don't see that as being opposed to the WHOPR ideas. It's not like WHOPR will prohibit that approach. It's a limiting case. > In particular, as consumer > machines get larger memories and more processors, the assumption that > we cannot see all of the functions bodies gets more questionable, > especially for modest sized apps that are the staple of the gcc > community. I question that assumption, and I especially question any assumption that gcc should only work for modest sized apps. Ian
