On Tue, 18 Dec 2012, Steven Bosscher wrote: > 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:
Well, loops were already preserved throughout the GIMPLE loop optimizer passes. > * What information is supposed to be transferable from GIMPLE loops to > RTL loops (e.g. number of iterations, ddg)? Transferable is everything cfgexpand.c arranges to transfer. Which is the absolute minimum as documented by "Loop querying". > * What's supposed to remain valid and what might need updating (e.g. > state of loop_father, number of latches, ...)? See above - it's already documented. All information that is valid according to the loop_state_satisfies_p () predicates. > * How are newly discovered loops handled (e.g. after node splitting of > an irreducible region, or a sting builtin expanded as a loop)? They are not handled. New loops need to be explicitely introduced (as happens with SESE region copying). What is not handled right now is if a previously irreducible region becomes reducible. > * 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? In general the pass is responsible for high-level transforms (like loop versioning). CFG hooks maintain loops for "simple" CFG modifications. fix_loop_structure is something that shouldn't be documented as interface - it should really work behind the scenes (I am still pondering on whether to make loop_optimizer_finalize or maybe instead loop_optimizer_init call it if LOOPS_NEED_FIXUP is set - an internal implementation detail flag - same as PROP_loops). Richard.
