Ping, I haven't checked in for a long time, but I've still been working on globalizing compiler.cfg.value-numbering (when I get spare time in between classes). Kind of got side-tracked because I was finding CFGs difficult to debug. I didn't really like the flat text compiler.cfg.debugger prints, and compiler.graphviz is pretty ad-hoc. So, I resolved to make a sensible graphviz vocab that I could then use to produce CFG representations (hence my previous email).
As for GVN, after I was able to see some examples in action, I got some preliminary results working (in a stupidly short burst of work after wrapping up graphviz; ugh). Right now it's kind of a simple iterate-till-fixpoint method---the "RPO Algorithm" from Simpson's dissertation (it essentially works like compiler.cfg.copy-prop does now; the GVN pass should subsume that in short order). Probably won't get much better than that for the purposes of my thesis since I just need to get something out there, but I'd be interested in improving it after I defend, which is currently planned for the summer. I haven't pushed the changes to my github yet. Is there any etiquette about handling commits I should know while working on that? For graphviz, I just used a separate repo in work/ for my personal purposes, then copied the result into extra/ to push to github, which seems pretty lame. Is it cool to just commit as much as I want in a branch, or does that clutter the git logs too much when it's merged later? Regards, --Alex Vondrak ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
