Can anyone give me an update on where we are with the dataflow branch? (DannyB? Zadeck?) TIA i think we are down to one or two regressions on a total of 4 platforms (IE 1 or two regressions total for all platforms) Where these platforms are i686-pc-linux, ia64-linux, powerpc-linux, and arm-sim DannyB: How serious are the regressions? just the usual a bit is wrong somewhere :) other than that, it is all speedup work to make the scanning persistent testsuite failures rather than bootstrap failures? yes i know someone tested mips-elf and found the same If we were to be aggressive, might it be reasonable to merge it to mainline soon (before they are resolved)? depends on how much of a speed hit you are willing to take What's the current performance hit? i don't even remember but it's pretty bad in some cases (>10%) because everything wants absolute fresh dataflow info Hmm :-( zadeck is the person who knows all the current details, i am more of a "this is a very fucked up regression" consultant and "how the hell do i do this" consultant :) I have faith that the speed up will happen with persistent scanning Hehe. Do we have a realistic due date then (given we're not quite ready yet)? well spark (a google person) is starting to help out with making the reference stuff persistent before that the target was realistically end of december or early january but probably sooner now that there are others Wow. I hadn't appreciated it's timeline was the very end of stage 1. so for correctness, no for speed parity, yes :) it's very hard to transform the entire backend of a compiler that relied on "almost-correct" and 'sometimes precise" info into something that works with always correct, always precise info, and not take a while I appreciate that Zadeck has done a very impressive job (probably even a minor miracle) You should also be aware that what i am telling you may all be stale info even though i spoke with him this morning, he knows the most up to date info and estimates Sure. Your update/insight is much appreciated. (this is my way of saying you should double check the info with him :P) Perhaps, you/we/someone should ask him to report a "state of the branch" executive summary to the gcc list. i'm happy to ask him to do so I know stevenb was hoping to use the new DF code in his CSE clean-up, but this dependency doesn't fit great with the timings. Do you expect a dramatic speed-up from spark's persistant reference improvements? Or will it be incremental. so, this is where all the current df time is spent as far as we can tell through profiling thus, i expect it will be the biggest speedup we can buy :) i think it will be dramatic, but i could be wrong DannyB: Thanks again. <-- sayle (~roger@c-68-42-41-246.hsd1.nm.comcast.net) has left #gcc