> On Wed, 8 Apr 2009, Richard Guenther wrote:
>
> > On Wed, 8 Apr 2009, Jan Hubicka wrote:
> > > - The nature of code duplication in between cleanup at end of block and
> > > cleanup in EH actually brings a lot of tail merging possibilities.
> > > I wonder if we can handle this somehow effectivly on SSA. In RTL world
> > > crossjumping would catch thse cases if it was not almost 100%
> > > ineffective
> > > by fact that we hardly re-use same register for temporaries.
> > >
> > > I wonder if there is resonable SSA optimization that would have
> > > similar
> > > effect as tail merging here or if we want to implement tail merging on
> > > gimple.
> > > - Can we somehow conclude that structure being desturcted dies after the
> > > destructors so all writes to it are dead already in early
> > > optimizations?
> > > That would allow a lot more DSE and cheaper inlining.
> > > - It is possible to make EH edges redirectable on RTL too. I wonder
> > > if it is worth the effort however.
> > > - We ought to be able to prove finitarity of simple loops so we can
> > > DCE more early and won't rely on full loop unrolling to get rid of
> > > empty loops originally initializing dead arrays.
> >
> > I wonder if CD-DCE should not catch this, but I see that for
> >
> > for(i=0;i<4;++i)
> > ;
> >
> > we do
> >
> > Marking useful stmt: if (i_1 <= 3)
> >
> > which is already a problem if we want to DCE the loop. Can we
> > mark the controlling predicate necessary somehow only if we
> > mark a stmt necessary in the BBs it controls?
>
> Ah, it can do it but ...
>
> /* Prevent the loops from being removed. We must keep the infinite
> loops,
> and we currently do not have a means to recognize the finite
> ones. */
> FOR_EACH_BB (bb)
> {
> edge_iterator ei;
> FOR_EACH_EDGE (e, ei, bb->succs)
> if (e->flags & EDGE_DFS_BACK)
> mark_control_dependent_edges_necessary (e->dest, el);
> }
Yes, this is what I referred to.
I plan to write simple predicate that will do similar analysis as number
of iterations code, just be more relaxed.
For instance
for (i=0; i<max; i+=anystride)
can be optimized out for signed counter relying that overflow can jump
in between max...INT_MAX
togehter with loops of style
for (i=0; i<max; i++)
in unsigned, and for MAX known and safely away from end of type we
should prove finiteness in most common cases.
I was wondering if loops of form
for (i=0; ....; i++)
a[i]
can be assumed finite because eventaully a[i] would get to unallocated
memory otherwise. This is however similar to inifinite recursion
a()
{
...nonlooping...
a();
}
will either overflow stack or be finite. We previously concluded here
it is invalid to optimize out such function call..
>
> thus what we could do is initialize loops and use number of iterations
> analysis here and mark only the back edge of those we do not know
> the number of iterations. Of course that is both expensive.
How far did we get with presistence of loop structures? This is
probably bit we can stick somewhere and make DCE and pureconst to use
it.
Honza
>
> Richard.
