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

[Garrison Venn]

Bummer, I had a feeling I was only solving the test case that pertained to my problem: the clobbering of the
register, used by the selector's return, by intervening instructions (those between the llvm.eh.exception call 
and the llvm.eh.selector call). The forcing of the selector's exception argument got rid of a bitcast problem, 
and I imagined any other potential operation, that manifested itself after the reorder. So now I've got a hacked 
version of DwarfEHPrepare that only works for my use case. :-) I guess it is time to look at SSAUpdator even 
though this will not fix the selector argument problem.

So my new conservative IR generation resolution is:

1) Execute llvm.eh.exception as the first instruction of the landing pad.
2) Execute llvm.eh.selector as the second instruction of that landing pad.

Although llvm currently allows more flexibility, holding to those two
resolutions will potentially avoid the trashing of llvm.eh.selector's 
return.

Thanks for the response

Garrison



On Feb 11, 2010, at 15:34, Duncan Sands wrote:

> 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.
>