On Tue, Dec 18, 2012 at 1:42 PM, Richard Biener wrote: > Thus I'd welcome hints at what information you are currently > missing
I think the documentation for the loops maintenance should document those things that are different from before. Before loops were maintained, the world was easy: Everything was refreshed every time loops were re-discovered. With maintained loops, you're implicitly making a guarantee of sorts that some information remains valid, and that should be documented. For example: * What information is supposed to be transferable from GIMPLE loops to RTL loops (e.g. number of iterations, ddg)? * What's supposed to remain valid and what might need updating (e.g. state of loop_father, number of latches, ...)? * How are newly discovered loops handled (e.g. after node splitting of an irreducible region, or a sting builtin expanded as a loop)? * If a pass might change loops, who is responsible for updating the loop tree? If it's the pass itself, what parts should be updated and what's the API for it, and what can be left to fix_loop_structure? Ciao! Steven
