On Thu, 2006-10-26 at 00:45 +0200, Zdenek Dvorak wrote: > actually, that will be trivial once jump threading updates loop properly > (I have a patch for that). I'd like to see that.
I recall poking at having threading update things like loop exit points and gave up. The problem is you could thread to a loop exit, which in turn might move the loop exit edge to a new point in the CFG. Furthermore, all the statements dominated by the new loop exit edge are no longer in the loop (when they previously were part of the loop). It's possible these problems could be solved by querying the dominator structures, but IIRC they aren't accurate at this point. Your updates may be simpler/easier since you're updating something different. [ This was a couple years ago, so if I've got details wrong, please forgive me. ] > Which is IMHO good, as it will at least ensure that they preserve loops, > in case it is really relevant for them -- just now, I do not see how > code motion could affect loop structures (unless it changes CFG) -- do > you have some concrete example of transformation that might be made > more problematic by the existence of LOOP_HEADER node? It wasn't a matter of changing the loop structure -- the RTL loop optimizer had 3 or 4 notes IIRC and the location of each note in relation to code labels and other insns was important. Code motion would sometimes place an insn between the note and a label. That in turn caused the loop optimizer to barf. There were also problems with edge splitting doing similar kinds of things. While I don't necessarily forsee you running into the exact same set of problems, experience tells us that you do need to be aware of these kinds of issues and plan appropriately for them. jeff
