[llvm-commits] [llvm-gcc-4.2] r80850 - in /llvm-gcc-4.2/tags/Apple/llvmgcc42-2306/gcc: except.c llvm-convert.cpp

[Eric Christopher]

On Sep 3, 2009, at 10:06 AM, Duncan Sands wrote:

> Hi Eric,
>
>> Yes, this does fail. As I went through just about every test in  
>> llvm and llvm-gcc including the single source tests, and apparently  
>> wasted a bunch of time doing so, why didn't you check this in when  
>> you made this patch originally? :)
>
> because several eh tests in the full llvm testsuite fail due to this,
> as well as several gcc tests in testsuite/g++.dg/eh.  One more test
> seemed pointless.  I can only imagine you made a mistake and tested a
> version of llvm-gcc without your change...
>

I'm never one to discount user error :) I'm just glad I have a  
testcase and...

>> At any rate the existing behavior is quite, quite wrong and the  
>> correct fix will just need to be something more.
>
> Yes, that's true, and in fact I started working on this already.
> What needs to happen is that llvm-gcc should output an "unwind"
> instruction, rather than call _Unwind_Resume.  When the inliner
> inlines code containing an unwind through an invoke callsite,
> the invoke+unwind cancel each other, turning into a jump.  This
> means you don't end up with invoke of _Unwind_Resume like right
> now.  So the eh.selector calls no longer end up in the landing
> pad of the invoke-of-_Unwind_Resume, which is the wrong place as
> far as the unwinder is concerned - see the testcase [*].
>
> Once the inliner has finished, it is safe to turn the "unwind"
> into a call to _Unwind_Resume.  I already taught codegen to
> do this.
>
> It's trivial to teach llvm-gcc to output "unwind" - try it and
> your testcase should be fixed!
>
> Unfortunately, there's a problem.  The invoke+unwind cancellation
> can leave eh.selector calls floating in the middle of nowhere.
> In itself that's ok.  But at codegen time they need to be moved
> to any landing pads from which the eh.selector call is reachable.
> And they need to be placed there in the right order.  This is
> doable, but tricky - I didn't do it yet though.  There was a
> similar but simpler problem for eh.exception calls, but I already
> taught codegen how to handle that one.
>
> Rather than moving around selectors during codegen, another  
> possibility
> is to have the inliner take care of placing the selectors in a good
> place when it cancels an invoke-of-unwind.
>

*nod* All of this makes sense. I'll wait for the other email you were  
going to send as well.  Thanks for everything!

> Finally, a workaround for all this is to not inline through invokes.
> Simple and probably not even that costly in terms of code slowdown.

Aha. This may do nicely as a workaround...

-eric