This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Update loop docs
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.