<br><br><div class="gmail_quote">On Sun, Sep 26, 2010 at 1:44 PM, 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 20:13, Nathan Jeffords <<a href="mailto:blunted2night@gmail.com">blunted2night@gmail.com</a>> wrote:<br>
> I believe the perceived problem with using eh.exception is that<br>
> is disassociates the source of the value with the invoke instruction that<br>
> generated it. As far as reusing the landing pad, that is still possible, it<br>
> would just require a phi node in the landing pad to bring all the different<br>
> exception values together into one that could be processed by the exception<br>
> handling code.<br>
<br>
</div>Let me see if I got it right...<br>
<br>
Invokes have a specific landing pad, so you can define precisely all<br>
predecessors of a landing pad. But the call to the @eh.exception can<br>
be made anywhere. You shouldn't, but you can. Doing it via<br>
predecessors or named values + PHI nodes yields exactly the same<br>
semantics, but the second links the value to the exception and forces<br>
the implementation to use the PHI nodes at the beginning of the<br>
landing pad (since anywhere else would be an error).<br>
<br>
In that case, you're forcing the user to implement the exception<br>
handling correctly without using any new EH specific constructs. Makes<br>
sense...<br>
<br>
But, that is as far as it goes. The examples on getting the type and<br>
relying on that won't work at all on dwarf debugging. As long as the<br>
only difference is the named value + PHI nodes, I guess it would work.<br>
I would recommend you to test also on Linux and Mac, especially with<br>
GCC, to make sure it didn't hurt the current implementation.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
As a secondary issue, I would prefer to have it typed, though. ;) I<br>
know you're creating the value, but it makes it more difficult when<br>
building the PHI node, if you get it wrong with another value of<br>
different type.<br>
<font color="#888888"><br></font></blockquote><div><br></div><div>I don't understand you concern here, this case would be no different that this:</div><div><br></div><div>...</div><div>path1:</div><div>  %x1 = mul i32 %a, %b</div>
<div>  br label %final</div><div>path2:</div><div>  %x2 = mul i32 %c, %d</div><div>  br label %final</div><div>final:</div><div>  %x = phi i32 [%x1, path1], [%x2, path2]</div><div>...</div><div><br></div><div>The "exception" value will *always* be i8*, it is not possible for it to be anything different.</div>
<div><br></div><div>In the end, this a minor parser detail and it is not terribly important to me one way or the other.</div><div><br></div><div><br></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></div></div></blockquote><div><br></div><div>thanks,</div><div>-Nathan </div></div><br>