On Thu, 03 Feb 2011 13:54:05 EST erik quanstrom <quans...@quanstro.net> wrote: > On Thu Feb 3 13:33:52 EST 2011, bakul+pl...@bitblocks.com wrote: > > On Thu, 03 Feb 2011 13:11:07 EST erik quanstrom <quans...@quanstro.net> wr > ote: > > > > I agree with their goal but not its execution. I think a > > > > toolkit for manipulating graph based program representations > > > > to build optimizing compilers is a great idea but did they > > > > do it in C++? > > > > > > are you sure that the problem isn't the graph representation? > > > gcc also takes a graph-based approach. > > > > What problem? > > the problem you yourself mentioned. gcc/llvm/etc have seem > to have produced monsterously huge piles of code, out of all > proportion to the problem at hand. > > i believe you're putting forth the theory that llvm is huge > because it's c++. and i'm not so sure.
I must also say llvm has a lot of functionality. But even so there is a lot of bloat. Let me just say the bloat is due to many factors but it has far *less* to do with graphs. Download llvm and take a peek. I think the chosen language and the habits it promotes and the "impedance match" with the problem domain does play a significant role. At any rate, a graph representation would have `data' bloat if any, but not so much code bloat! > > All programs are graphs in any case. Optimizations in effect > > replace one subgraph with another that has better properties. > > Global optimizers need to keep many more graphs in memory. > > But you can take short cuts when not optimizing -- if you > > know a graph is not going to change under you, you can > > generate code incrementally and may not even need to keep all > > subgraphs in memory. > > all programs are graphs implies that we should represent them > as graphs? Or something equivalent. Example: How do you know moving an expression out of a for loop is valid? The optimizer needs to understand the control flow. The _model_ is graph based. But if you look at c/c++ code, typically the "graphiness" is hidden in a mess of ptrs. Which makes equivalent xforms on the representation harder. > seem to get by fine using pseudoassembler instead of a graph. > they are also quite a bit faster and smaller than their graph-based > counterparts.
