On Wed, 8 Apr 2009, Jan Hubicka wrote: > Some remaining issues: > - FILTER_EXPR/OBJ_REF_EXPR is currently handled in quite dangerous way. > Original Rth's code made them quite 100% volatile. Now we can PRE them. > The FILTER_EXPR/OBJ_REF_EXPR are really hard registers in RTL world that > are set by EH runtime on EH edges from throwing statement to handler > (not at RESX edges) and they are used by pre-landing pads and also by > RESX code. > > It would be more precise if RESX instruction took FILTER_EXPR/OBJ_REF_EXPR > value as argument (since it really uses the values) so we can kill > magicness > of the sets. Problem is that I don't think there is good SSA > representation > for register that implicitly change over edges. > > Take the example > > call (); EH edge to handler 1: > .... > > receiver 1: > tmp1 = filter_expr; > tmp2 = obj_ref_expr; > call2 (); EH edge to handler 2 > label1: > filter_expr = tmp1 > obj_ref_expr = tmp2 > resx (tmp1, tmp2) > > > handler 2: > tmp3 = filter_expr; > tmp4 = obj_ref_expr; > if (conditional) > goto label1: > else > filter_expr = tmp3 > obj_ref_expr = tmp4 > resx (tmp3, tmp4); > > In this case tmp1 != tmp3 and tmp2 != tmp4 and thus it is invalid to > optimize > second resx to (tmp1, tmp3). There is nothing to model this. > I wonder if FILTER_EXPR/OBJ_REF_EXPR can't be best handled by just being > volatile to majority of optimizations (i.e. assumed to change value all > the time) > and handle this in copyprop/PRE as specal case invalidating the value > across > EH edges?
Hm, what we have now is indeed somewhat dangerous. Correct would be to make them global volatile variables and thus have volatile loads and stores. I don't see any easy way of killing the values on EH edges - but certainly we could teach the VN to do this. So in the end non-volatileness might work as well, if the loaded values are properly used by sth. I can have a look into the current state in the VN if you have a testcase that produces the above CFG for example. > - 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? Otherwise there is the empty loop removal pass ... Richard.
