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.