[LLVMdev] LLVM Exception Handling

[Nathan Jeffords]

On Sun, Sep 26, 2010 at 1:44 PM, Renato Golin <rengolin at systemcall.org>wrote:

> On 26 September 2010 20:13, Nathan Jeffords <blunted2night at gmail.com>
> wrote:
> > I believe the perceived problem with using eh.exception is that
> > is disassociates the source of the value with the invoke instruction that
> > generated it. As far as reusing the landing pad, that is still possible,
> it
> > would just require a phi node in the landing pad to bring all the
> different
> > exception values together into one that could be processed by the
> exception
> > handling code.
>
> Let me see if I got it right...
>
> Invokes have a specific landing pad, so you can define precisely all
> predecessors of a landing pad. But the call to the @eh.exception can
> be made anywhere. You shouldn't, but you can. Doing it via
> predecessors or named values + PHI nodes yields exactly the same
> semantics, but the second links the value to the exception and forces
> the implementation to use the PHI nodes at the beginning of the
> landing pad (since anywhere else would be an error).
>
> In that case, you're forcing the user to implement the exception
> handling correctly without using any new EH specific constructs. Makes
> sense...
>
> But, that is as far as it goes. The examples on getting the type and
> relying on that won't work at all on dwarf debugging. As long as the
> only difference is the named value + PHI nodes, I guess it would work.
> I would recommend you to test also on Linux and Mac, especially with
> GCC, to make sure it didn't hurt the current implementation.
>

Exactly. At this point, the patch I attached to my original post doesn't
full deal with dwarf or sjlj exception handling completely. It only deals
with the version of exception handling that is generated when LowerInvoke
generates expensive but correct exception handling via the
'-enable-correct-eh-support' option. I don't see any reason updating dwarf &
sjlj to work with the new representation would be problematic. I only
included the patch in-case anyone was interested in the implementation so
far.

To get this to a point where it is commit ready would require more work and
some coordination with at clang and a lot of testing. I believe their are
some other projects using LLVM exception handling (LDC that I know of).
Though I think the changes needed would be minimal.


>
> As a secondary issue, I would prefer to have it typed, though. ;) I
> know you're creating the value, but it makes it more difficult when
> building the PHI node, if you get it wrong with another value of
> different type.
>
>
I don't understand you concern here, this case would be no different that
this:

...
path1:
  %x1 = mul i32 %a, %b
  br label %final
path2:
  %x2 = mul i32 %c, %d
  br label %final
final:
  %x = phi i32 [%x1, path1], [%x2, path2]
...

The "exception" value will *always* be i8*, it is not possible for it to be
anything different.

In the end, this a minor parser detail and it is not terribly important to
me one way or the other.


--
> cheers,
> --renato
>
> http://systemcall.org/
>
> Reclaim your digital rights, eliminate DRM, learn more at
> http://www.defectivebydesign.org/what_is_drm
>

thanks,
-Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100926/d8aa07f3/attachment.html>