llvm dev - Aug 2009 - [LLVMdev] Throwing function being marked nounwind under optimzation?

All,

The following relatively simple function is behaving oddly under SJLJ  
exception handling. Specifically, it's being diagnosed by the  
optimizer as being a nounwind function, which is obviously incorrect.

 From what I can tell so far, something is going wrong analyzing the  
call to __cxa_end_catch()
   invoke arm_apcscc  void @__cxa_end_catch()
           to label %Unwind unwind label %lpad121
Something thinks that this invoke will always take the unwind path,  
which isn't the case, and marks the Unwind block as unreachable. As a  
consequence of that, the call to _Unwind_SjLj_Resume() is optimized  
away, and thus the function is considered to not throw in PruneEH.cpp.  
Very strange stuff.

Thoughts on how to proceed in figuring out the root cause of what's  
going wrong?


bool ShouldThrow;

int throws()
   try
{
   if (ShouldThrow) throw 7; return 123;
} catch (...) {
   printf("'throws' threw an exception: rethrowing!\n");
   throw;
}

It would help if you post the -O0 and -O1bitcode files.

Does it reproduce with opt -O1? If so, use -debug-pass= to figure out  
when things started going wrong.

Does it make sense to compare the bitcode against code generated for  
x86 target?

Evan


On Aug 16, 2009, at 11:46 AM, Jim Grosbach wrote:
> All,
>
> The following relatively simple function is behaving oddly under SJLJ
> exception handling. Specifically, it's being diagnosed by the
> optimizer as being a nounwind function, which is obviously incorrect.
>
> From what I can tell so far, something is going wrong analyzing the
> call to __cxa_end_catch()
>   invoke arm_apcscc  void @__cxa_end_catch()
>           to label %Unwind unwind label %lpad121
> Something thinks that this invoke will always take the unwind path,
> which isn't the case, and marks the Unwind block as unreachable. As a
> consequence of that, the call to _Unwind_SjLj_Resume() is optimized
> away, and thus the function is considered to not throw in PruneEH.cpp.
> Very strange stuff.
>
> Thoughts on how to proceed in figuring out the root cause of what's
> going wrong?
>
>
> bool ShouldThrow;
>
> int throws()
>   try
> {
>   if (ShouldThrow) throw 7; return 123;
> } catch (...) {
>   printf("'throws' threw an exception: rethrowing!\n");
>   throw;
> }
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Attached .bc files from -O0, -O1 and an X86 -O1. Comparing against the  
x86 code is somewhat useful, as the core control flow for EH should be  
the same. The SJLJ bits add a bit of wrapper around it and some  
annotations (call_site stuff).

It does reproduce when running "opt -O1." That's a good
suggestion.
Thanks. I'll see where that leads.

Comparing to the x86 output also makes good sense. Doing that is what  
led me noticing that the Unwind block was getting optimized away.


  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: function_try_block.O0.bc
Type: application/octet-stream
Size: 2400 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090816/c4b69780/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: function_try_block.O1.bc
Type: application/octet-stream
Size: 1664 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090816/c4b69780/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: function_try_block.x86.bc
Type: application/octet-stream
Size: 1616 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090816/c4b69780/attachment-0002.obj>
-------------- next part --------------


On Aug 16, 2009, at 1:03 PM, Evan Cheng wrote:
> It would help if you post the -O0 and -O1bitcode files.
>
> Does it reproduce with opt -O1? If so, use -debug-pass= to figure  
> out when things started going wrong.
>
> Does it make sense to compare the bitcode against code generated for  
> x86 target?
>
> Evan
>
>
> On Aug 16, 2009, at 11:46 AM, Jim Grosbach wrote:
>
>> All,
>>
>> The following relatively simple function is behaving oddly under SJLJ
>> exception handling. Specifically, it's being diagnosed by the
>> optimizer as being a nounwind function, which is obviously incorrect.
>>
>> From what I can tell so far, something is going wrong analyzing the
>> call to __cxa_end_catch()
>>  invoke arm_apcscc  void @__cxa_end_catch()
>>          to label %Unwind unwind label %lpad121
>> Something thinks that this invoke will always take the unwind path,
>> which isn't the case, and marks the Unwind block as unreachable. As
a
>> consequence of that, the call to _Unwind_SjLj_Resume() is optimized
>> away, and thus the function is considered to not throw in  
>> PruneEH.cpp.
>> Very strange stuff.
>>
>> Thoughts on how to proceed in figuring out the root cause of what's
>> going wrong?
>>
>>
>> bool ShouldThrow;
>>
>> int throws()
>>  try
>> {
>>  if (ShouldThrow) throw 7; return 123;
>> } catch (...) {
>>  printf("'throws' threw an exception:
rethrowing!\n");
>>  throw;
>> }
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>