[LLVMdev] Test approach to handling clobbering llvm.eh.selector return

[Duncan Sands]

Hi Garrison,

> I hacked together a version of DwarfEHPrepare.cpp which tries to deal with the ordering of llvm.eh.exception and llvm.eh.selector.
> The hacked is contained within the attached patch.

it looks like you tried to copy the code for eh.exception.  There are two
problems with this: (1) the eh.exception code really needs to be rewritten
to make use of the new SSAUpdator (then all the mucking around with domtree
can go away; it's quite tricky to preserve dominfo when updating the IR, and
the whole dom approach is inefficient), and (2) the eh.selector case is much
more complicated because selectors carry type infos (and filters) around with
them.  Sadly, you can just move selectors to the landing pad(s) their exception
objects come from, since you might end up with multiple selectors there, and
because the order of type infos matters, you can't just concatenate the type
info lists.  It's worse for filters because these have extra, hidden, semantics
that are enforced by the personality function.

> 2) To force the exception argument of llvm.eh.selector to come from the return of the preceding llvm.eh.exception call.

This sounds bogus.  llvm.eh.selector compares it's exception argument with the
list of type infos, and returns an appropriate index.  There is no connection
with "the current exception" in general, or the preceeding llvm.eh.exception
call in particular.  This is one of the problems dealing with eh.selector when
the call is far from the landing pad where the exception was caught.  That said,
this doesn't work properly right now anyway.

> 5) To include loads and stores of llvm.eh.selector to the register promotion optimization.

The register promotion should be reworked using SSAUpdator, as I mentioned
above.

> Although the patch deals with the llvm.eh.selector's exception argument, it does not know how to deal with
> its other arguments. This would not be a problem for say type infos, and I believe the personality function since
> these arguments must be direct references to Globals. However I'm unclear on filters, as I have never used
> them. Regardless I ignored this issue since you have a full understanding as to whether this is an issue or 
> not, and as to how to fix it if it is relevant. 

See above.

Ciao,

Duncan.