[llvm-commits] [llvm-gcc-4.2] r80850 - in /llvm-gcc-4.2/tags/Apple/llvmgcc42-2306/gcc: except.c llvm-convert.cpp
Bill Wendling
isanbard at gmail.com
Fri Sep 4 06:48:20 PDT 2009
On Sep 4, 2009, at 2:14 AM, Duncan Sands <baldrick at free.fr> wrote:
> Hi Eric,
>
>> Found one myself in the project I'm trying to get working. Assert
>> in debug mode with the catch blocks lost/added weren't equal. The
>> generated llvm looks fine in practice but the invoke goes to an
>> empty block that forwards to the unwind block.
>
> you get this failure if the selectors are not in the landing pad, and
> not in the successor of the landing pad. Then codegen doesn't know
> which invokes to associate them with. To fix this, codegen needs to
> start from each landing pad and look for all selector calls that use
> its exception value (= result of eh.exception call), so it can
> associate
> its catches with the invoke. However because dwarf catches are
> ordered,
> it is not enough to find the selector calls, you also have to order
> them
> correctly, which in theory is hard because there might be all kinds of
> control flow logic between the landing pad and the selector calls,
> making it tricky to know which one comes first. In practice however
> the
> output of llvm-gcc is very regular, and probably most real cases can
> be
> handled fairly easily.
>
> For the moment, I think you should just turn off inlining through
> invoke calls.
>
> In the long term, I think lists of globals to catch should be attached
> directly to the invoke using some kind of metadata, rather than using
> eh.selector calls. Then everything can be handled trivially (see
> later
> email).
>
Yes! I really want this llvm.eh.selector must be at the beginning of
landing pad voodoo to go away. It adds nothing and makes for all types
if headaches.
I hate it when intrinsics are position dependent.
-bw
More information about the llvm-commits
mailing list