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

[Bill Wendling]

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