<br><br><div class="gmail_quote">On Sun, Sep 26, 2010 at 11:27 AM, Renato Golin <span dir="ltr"><<a href="mailto:rengolin@systemcall.org">rengolin@systemcall.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 26 September 2010 18:56, Nathan Jeffords <<a href="mailto:blunted2night@gmail.com">blunted2night@gmail.com</a>> wrote:<br>
> The syntax for the invoke instruction is a little misleading. %x is a value<br>
> that is being generated by the instruction, not passed to is. It is no<br>
> different in that regard as to say '%x = call @eh.exception ...'. Since you<br>
> don't specify the type in that type of assignment, I chose not to here<br>
> either.<br>
<br>
</div>I see, you're saving a call to @llvm.eh.exception in the IR. But is<br>
that really necessary?<br>
<br>
I mean, if you're using sj/lj you can always optimize them away if not<br>
using, but on dwarf exceptions that is really a bonus. Several invokes<br>
can unwind to a single landing pad, so it makes more sense to put the<br>
call on the landing pad, because it is there that the exception<br>
structure is going to be used.<br>
<br>
Nevertheless, the docs say having the eh.exception in the landing pad<br>
is actually a limitation of the IR, but I honestly don't know what<br>
that limitation is. That could be what you're trying to fix, but I can<br>
only see that it'll be better for sj/lj, I can't see how that's better<br>
for dwarf exceptions.<br>
<div class="im"><br></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
<br>
> I agree; this change is not attempting to change how exception handling<br>
> works, just provide a small change in how it is represented in the IR to<br>
> make it more direct. Especially for users not using gcc/dwarf exception<br>
> handling (I hope to attempt an SEH implementation)<br>
<br>
</div>I agree that it's simpler for sj/lj, but you have to be careful not to<br>
break the dwarf contract between the three parties: eh-lib, eh-tables<br>
and try/catch blocks. It is really tricky to make sure that contract<br>
is working, the easiest being having a huge test codebase to run<br>
before/after your changes and the surest having Knuth to prove it's<br>
right. ;)<br>
<br>
Whatever your changes are, just remember that the syntax has to make<br>
sense for dwarf EH users as well. Removing clutter from sj/lj and<br>
introducing it to dwarf is no gain.<br>
<font color="#888888"><br></font></blockquote><div><br></div><div>Once again, I fully agree, and I think that this approach changes nothing semantically about how dwarf exception handling works.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888">
--<br>
</font><div><div></div><div class="h5">cheers,<br>
--renato<br>
<br>
<a href="http://systemcall.org/" target="_blank">http://systemcall.org/</a><br>
<br>
Reclaim your digital rights, eliminate DRM, learn more at<br>
<a href="http://www.defectivebydesign.org/what_is_drm" target="_blank">http://www.defectivebydesign.org/what_is_drm</a><br>
</div></div></blockquote></div><br><div><br></div><div>I will continue my response in your next message.</div><div><br></div><div>-Nathan</div>