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>
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. 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. -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm
On 26 September 2010 21:44, Renato Golin <rengolin at systemcall.org> wrote:> relying on that won't work at all on dwarf debugging. As long as theSorry, I meant "Dwarf exception handling"... ;) -- 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 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>