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

[Duncan Sands]

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

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

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

Ciao,

Duncan.