On Sun, Sep 26, 2010 at 4:19 AM, Renato Golin <rengolin at systemcall.org>wrote:> On 25 September 2010 23:46, Nathan Jeffords <blunted2night at gmail.com> > wrote: > > catch: > > %v = ptrtoint i8 * %x to i32 > > %r = icmp eq i32 %v, 255 > > br i1 %r, label %bad, label %worse > > bad: > > ret i32 -1 > > worse: > > ret i32 -2 > > } > > If I understood correctly, you're trying to pass the clean-up flag > through %x directly on the invoke call. But later avoid the > eh.exception call, assuming that was in %x. > > The problem is that you're mixing two concepts: The exception > structure contains information about the object that was thrown and > not a "good" number. That's the role of the clean-up flag (in case the > catch blocks can't deal with the exception) or the landing pads (that > should reflect the return values the user asked for in their > programs). > > It's the users role to tell what's good and what's not (return values > included). the only thing you (compiler) can do is to explode > prematurely in case you can't properly catch the error (ie. throw > inside throw, throw inside delete, etc). >The argument to the unwind instruction is always an i8* pointer, which in the case of dwarf exception handling would be the allocated exception object. I did cheat for the example, but this also demonstrates that an arbitrary value could be passed if using an LLVM specific exception handling implementation like the setjmp/longjmp version provided by the LowerInvoke pass.> > If that's the case, your implementation will not work for dwarf > exceptions, and I wouldn't recommend having an *invoke* syntax for > each type of exception handling mechanism. > > Other question: why are you passing untyped %x? I haven't seen any > untyped variable in LLVM, so far, and I think it's good to be > redundant in this case. That alone would have caught the mistake. If > you need an i32 (for your bad/worse comparison), throwing i8* would > have hinted that you crossed the concepts. > >The syntax for the invoke instruction is a little misleading. %x is a value that is being generated by the instruction, not passed to is. It is no different in that regard as to say '%x = call @eh.exception ...'. Since you don't specify the type in that type of assignment, I chose not to here either.> > On a side note... > > Exception handling was designed by the devil himself. Part of the flow > control is designed by the user (try/catch blocks, throw > specifications), part of it is designed by the compiler, in exception > tables (specific unwinding instructions and types), and part by the > library writers (unwinding and personality routines). All that, > decided in three different time frames, by three different kinds of > developers, have to communicate perfectly in run time. > > It'd be very difficult for the compiler to optimize automatically > without breaking run-time assumptions. All of that is controlled by > different ABIs, that make sure all three universes are talking the > same language. You can't change one without changing all the others... > >I agree; this change is not attempting to change how exception handling works, just provide a small change in how it is represented in the IR to make it more direct. Especially for users not using gcc/dwarf exception handling (I hope to attempt an SEH implementation)> To be honest, I'm still surprised that it actually works at all! ;) > > -- > cheers, > --renato > > http://systemcall.org/ > > Reclaim your digital rights, eliminate DRM, learn more at > http://www.defectivebydesign.org/what_is_drm >Thanks for the feedback -Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100926/8451d346/attachment.html>
On 26 September 2010 18:56, Nathan Jeffords <blunted2night at gmail.com> wrote:> The syntax for the invoke instruction is a little misleading. %x is a value > that is being generated by the instruction, not passed to is. It is no > different in that regard as to say '%x = call @eh.exception ...'. Since you > don't specify the type in that type of assignment, I chose not to here > either.I see, you're saving a call to @llvm.eh.exception in the IR. But is that really necessary? I mean, if you're using sj/lj you can always optimize them away if not using, but on dwarf exceptions that is really a bonus. Several invokes can unwind to a single landing pad, so it makes more sense to put the call on the landing pad, because it is there that the exception structure is going to be used. Nevertheless, the docs say having the eh.exception in the landing pad is actually a limitation of the IR, but I honestly don't know what that limitation is. That could be what you're trying to fix, but I can only see that it'll be better for sj/lj, I can't see how that's better for dwarf exceptions.> I agree; this change is not attempting to change how exception handling > works, just provide a small change in how it is represented in the IR to > make it more direct. Especially for users not using gcc/dwarf exception > handling (I hope to attempt an SEH implementation)I agree that it's simpler for sj/lj, but you have to be careful not to break the dwarf contract between the three parties: eh-lib, eh-tables and try/catch blocks. It is really tricky to make sure that contract is working, the easiest being having a huge test codebase to run before/after your changes and the surest having Knuth to prove it's right. ;) Whatever your changes are, just remember that the syntax has to make sense for dwarf EH users as well. Removing clutter from sj/lj and introducing it to dwarf is no gain. -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm
On Sun, Sep 26, 2010 at 11:27 AM, Renato Golin <rengolin at systemcall.org>wrote:> On 26 September 2010 18:56, Nathan Jeffords <blunted2night at gmail.com> > wrote: > > The syntax for the invoke instruction is a little misleading. %x is a > value > > that is being generated by the instruction, not passed to is. It is no > > different in that regard as to say '%x = call @eh.exception ...'. Since > you > > don't specify the type in that type of assignment, I chose not to here > > either. > > I see, you're saving a call to @llvm.eh.exception in the IR. But is > that really necessary? > > I mean, if you're using sj/lj you can always optimize them away if not > using, but on dwarf exceptions that is really a bonus. Several invokes > can unwind to a single landing pad, so it makes more sense to put the > call on the landing pad, because it is there that the exception > structure is going to be used. > > Nevertheless, the docs say having the eh.exception in the landing pad > is actually a limitation of the IR, but I honestly don't know what > that limitation is. That could be what you're trying to fix, but I can > only see that it'll be better for sj/lj, I can't see how that's better > for dwarf exceptions. > >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.> > > I agree; this change is not attempting to change how exception handling > > works, just provide a small change in how it is represented in the IR to > > make it more direct. Especially for users not using gcc/dwarf exception > > handling (I hope to attempt an SEH implementation) > > I agree that it's simpler for sj/lj, but you have to be careful not to > break the dwarf contract between the three parties: eh-lib, eh-tables > and try/catch blocks. It is really tricky to make sure that contract > is working, the easiest being having a huge test codebase to run > before/after your changes and the surest having Knuth to prove it's > right. ;) > > Whatever your changes are, just remember that the syntax has to make > sense for dwarf EH users as well. Removing clutter from sj/lj and > introducing it to dwarf is no gain. > >Once again, I fully agree, and I think that this approach changes nothing semantically about how dwarf exception handling works.> -- > cheers, > --renato > > http://systemcall.org/ > > Reclaim your digital rights, eliminate DRM, learn more at > http://www.defectivebydesign.org/what_is_drm >I will continue my response in your next message. -Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100926/4e9c68b7/attachment.html>