[LLVMdev] Assertion failure in llc when using exception handling
shivramk at gmail.com
Thu Jun 10 03:13:21 PDT 2010
Forgot to reply all.
Duncan suggested that I put the selector call before the store but that
didn't help. I get the same assertion failure.
On Thu, Jun 10, 2010 at 2:50 PM, Shivram Khandeparker <shivramk at gmail.com>wrote:
> HI Duncan,
> On Thu, Jun 10, 2010 at 1:58 PM, Duncan Sands <baldrick at free.fr> wrote:
>> an unfortunate weakness of the code generators is that they require calls
>> eh.selector to be in a landing pad (landing pad = where an invoke unwinds
>> to). They can also handle some simple cases when the selector call is
>> the landing pad. In practice, as long as the original call to eh.selector
>> you generate is in a landing pad, and at the start of the landing pad
>> after the eh.exception call and any phi nodes) it is intended that the
>> logic is good enough to handle any situations caused by optimization. Was
>> original call at the start of a landing pad?
> I am aware of this. All of the landing pads in my original code look like
> the following
> lpad: ; preds = %return7
> %46 = call i8* @llvm.eh.exception() ; <i8*> [#uses=2]
> store i8* %46, i8** %22
> %47 = call i32 (i8*, i8*, ...)* @llvm.eh.selector(i8* %46, i8* bitcast
> (i32 (...)* @__gxx_personality_v0 to i8*), i8* null) ; <i32> [#uses=0]
> br label %destructor
> eh.selector always follows the eh.exception call and the store.
>> By the way, there are various ways of fixing this codegen problem. But
>> there is a plan to redesign exception handling in LLVM, it seems pointless
>> spend much time on it.
> It would be great if you could suggest a workaround till exception handling
> in LLVM gets redesigned. I would really like to get this working as soon as
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev