[LLVMdev] Clobbering llvm.eh.selector return

[Garrison Venn]

Funny I remember that code (DwarfEHPrepare), wondering at the time why it was doing this. Thanks for your response,
as I can now stop trying figure out how I am introducing this error, and more importantly now will be able to go back to
DwarfEHPrepare, and understand it better knowing one of its purposes. However the result of my tests indicates that
the underlying register used by the exception/unwind (get/setGR(built in reg. index 1)), mechanism is shared for other uses.
If this is true, what criteria is used to identify whether this register is going to be used. I can image future efforts directed toward
changing or adding to the exception mechanism needing to know what to avoid before the passes that actually lower the graphs 
into machine/assembly code have been executed.

Thanks again for the info.

Garrison

On Feb 5, 2010, at 15:41, Duncan Sands wrote:

> Hi Garrison,
> 
>> I accidentally ran into a JIT scenario where a call instruction, executing an external non-generated C function, executed between a llvm.eh.exception and a llvm.eh.selector instruction would clobber the register (register index __builtin_eh_return_data_regno(1)), used by the return value of llvm.eh.selector. The behavior of the call depends on the function called even though none of the functions I have tested played with the exception mechanism--fprintfs and C functions with static variables initialized in a certain way do the trick. I am assuming that this is not a bug but rather that there is an unstated requirement that llvm.eh.exception, and llvm.eh.selector must be the first calls in any landing pad. Is this true?
> 
> no, it's a bug.  The DwarfEHPrepare is supposed to take care of moving such
> calls to the start of landing pads, but currently it only does this for
> eh.exception (eh.selector is harder for various reasons).  This is on my list
> of things to fix.
> 
> Ciao,
> 
> Duncan.