<br><br><div class="gmail_quote">On Sun, Sep 26, 2010 at 5:08 AM, Eugene Toder <span dir="ltr"><<a href="mailto:eltoder@gmail.com">eltoder@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I may me wrong, but I think Nathan used ints for demonstration<br>
purposes only. unwind always takes i8* argument that ideally should be<br>
a pointer to exception structure, variable %x in invoke is also typed<br>
i8*, it's not "untyped". Probably more llvm-ish syntax would be<br>
<br>
unwind i8* %x to label %catch<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
to show the type explicitly.<br></blockquote><div><br></div><div>Yes, I didn't specify a type because %x is an assignment (like '%x = call @eh.exception ...'). Admittedly this specify syntax is misleading. I think a syntax like:</div>
<div><br></div><div>invoke i32 @v(i32 %o)</div><div>  success %s to label %ok</div>  unwind %x to label %catch<div><br></div><div>would be more consistent and have the benefit better indicating what value is generated when branching to what label.</div>
<div> </div><div>[snip]</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Nathan -- is this approach simpler than using intrinsics @eh.throw<br>
(assuming it's added) and @eh.exception? The latter seems more<br>
flexible in supporting various levels of ABI (I think ideally LLVM<br>
exception handling should follow general platform ABI and also allow<br>
front-ends for specific languages generate code in accordance with<br>
language specific ABI).<br></blockquote><div><br></div><div>I don't know the specifics of all the platforms that LLVM may run on so this is a hard question to answer. I think looking at this as a representation and not an implementation may help. If it is assumed that all exception handling mechanisms fundamentally pass pointers to exception information than this representation would work, and it would be lowered to the appropriate platform specific representation by a platform specific pass. Another approach (that should be selectable by the compiler) would be for the code generator to lower this representation into what ever it would take to pass the unwind pointer argument to the catch block referenced by the invoke instruction to allow the compiler to be platform agnostic at the cost of some flexibility with regards to the types of options available with platform specific implementations. I do think that a direct representation is more desirable than one implemented via intrinsics. I think that that makes it easier for passes to deal with.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I going with invoke instruction that returns exception pointer (which<br>
feels right to me) maybe this is a good candidate for using union type<br>
-- invoke can produce a single result which is either normal return<br>
value or an exception pointer, since only one of the two values can be<br>
actually produced. This sounds logical but may be taking us too far<br>
from ABIs.<br>
<br></blockquote><div><br></div><div>This could work too if unions are going to be supported. Perhaps this could be another reason why LLVM needs unions. I don't now any details on the semantics of the existing union support, but for this purpose I think I can see a set of semantics. It would revolve around have a way tie what field of the union is valid to one or more basic blocks.</div>
<div><br></div><div>[snip]</div><div><br></div><div>Thanks for the feedback,</div><div><br></div><div>-Nathan</div><div><br></div></div>