On Wed, 8 Apr 2009, Jan Hubicka wrote:
> > 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.
I think the infrastructure is there but nobody tried to keep it
"alive" yet ;)
Richard.
