> 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.
Yep, but we definitly do want to DCE them (since we emit a lot of
redundant load+store pairs during lowering to handle case of possibly
throwing code inside cleanup) at least.
Having way to PRE them would be nice. I have code for early EH
lowering. Try....catch or exception_allowed regions basically expand to
something like
switch (filter_expr)
{
case 5: goto catch_region 1;
case 7: goto catch_region 2;
default: resx;
}
Thus I think is best done somewehre in the middle of
all_optimization_passes. Doing so is already win because most often RESX
expands to simple goto and we merge blocks and also because we use
switch expansion instead of ugly seqeunce of ifs.
In fact I forgot to write item in my list of experimental stuff and it
is lowering of those trivial RESX early (pre-inlining). It makes
ehclanup matching more interesting since we can see sequence of EH
regions merged together instead of single EH region, but it also saves
thousdands of BBs on Tramp.
Of course, it is possible to look when expanding the TRY...catch
receiver into incomming copies of still live FILTER_EXPRs and use the
temporaries instead of relying on SSA optimizers to work this out. But
it is not 100% trivial analysis.
>
> 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.
It should be try-catch inside catch of try-catch. I will try to write
one ;)
Honza
