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.

Reply via email to