Re: Documentation for loop infrastructure

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

Hello,

> >> Apologies for the previous incomplete reply.  Here's the rest of the
> >> comments I had for this patch.
> > 
> > here is the updated patch.  Daniel, did you write something regarding
> > the lambda framework, or should I do it?
> 
> I've attached a modified version with lambda docs.
> 
> Though i still have some questions about your version.
> > + @item @code{bsi_insert_on_edge_immediate_loop}: Inserts code on edge, splitting
> > + it if necessary.  Only works on GIMPLE.
> ^^^^^^^^^^^^^^^
> 
> Why is this not just part of bsi_insert_on_edge_immediate, and have it
> do nothing interesting if the loop structures don't exist?

historical reasons.  I would like to clean up similar issues sometime
soon (I would prefer to say "I plan to", but given my current schedule,
it seems too optimistic :-( )

> > + @item It makes updating of SSA form during loop transformations simpler.
> > + Without LCSSA, operations like loop unrolling may force creation of PHI
> > + nodes arbitrarily far from the loop, while in LCSSA, the SSA form can be
> > + updated locally.  However, since we only keep real operands in LCSSA, we
> > + cannot use this advantage (we could have local updating of real operands,
> > + but it is not much more efficient than to use generic SSA form updating
> > + for it as well; the amount of changes to SSA is the same).
> 
> I'm not sure i'd keep the commentary about this in.
> We can use the advantage for real operands, we just don't.
> You claim for real operands, it's not really an advantage anyway.

Not quite (the comment is really quite complicated, but so is the
situation).  Due to LCSSA, we need to make less changes to ssa form
for real operands during loop unrolling -- the changes are local.
So it would be possible to have a special-case ssa form updating code;
but since generic ssa form updating code is efficient enough, and we
would still need to run it for virtual operands, it does not make sense
to implement this special case.

This is probably not all that important, so I will consider changing the
comment.  The reason I included it there is that updating SSA form
during loop unrolling is one of major reasons other compilers (LLVM, at
least) use LCSSA, and I wanted to document somewhere the reasons for why
we do not do it.

> +Once a @code{lambda_loopnest} is obtained from the conversion
> +function, it can be transformed by using
> +@code{lambda_loopnest_transform}, which takes a transformation matrix
> +to apply.  Note that it is up to the caller to verify that the
> +transformation matrix is legal to apply to the loop (dependence
> +respecting, etc).

It might be good to mention lambda_transform_legal_p function here.

Zdenek