Kaylor, Andrew
2015-May-18 23:36 UTC
[LLVMdev] New EH representation for MSVC compatibility
> optimizing EH codepaths is not usually performance critical. >> Leaving aside the rest of the thread, I feel the need to refute this point in isolation. I've found that optimizing (usually simplifying and eliminating) exception paths ends up being *extremely* important for my workloads. Failing to optimize exception paths sufficiently tends to indirectly hurt things like inlining for example. Any design which starts with the assumption that optimizing exception paths isn't important is going to be extremely problematic for me.That's interesting. I wasn't thinking about performance so much as code size in my original comment. I've been looking at IR recently where code from multiple exception handlers was combined while still maintaining the basic control flow of the EH code. This kind of optimization is wreaking havoc for our current MSVC compatible EH implementation (hence the redesign), but I guess the Itanium ABI scheme doesn't have a problem with it. I suppose that is closely related to your concerns about inlining, I just hadn't made the connection. In theory the funclets should be able to share code blocks without any problem. The entry and exit points are the critical parts that make them funclets. I'm just not sure how we can get the optimization passes to recognize this fact while still meeting the MSVC runtime constraints. Reid's proposal of separate catch blocks should help with that, but I'm still not sure we'll want to use this representation for targets that don't need it. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150518/f9a8cf6f/attachment.html>
Reid Kleckner
2015-May-18 23:58 UTC
[LLVMdev] New EH representation for MSVC compatibility
On Mon, May 18, 2015 at 4:36 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote:> > optimizing EH codepaths is not usually performance critical. > > >> Leaving aside the rest of the thread, I feel the need to refute this > point in isolation. I've found that optimizing (usually simplifying and > eliminating) exception paths ends up being *extremely* important for my > workloads. Failing to optimize exception paths sufficiently tends to > indirectly hurt things like inlining for example. Any design which starts > with the assumption that optimizing exception paths isn't important is > going to be extremely problematic for me. >On the whole, the whole reason we've gone down this path is to support stronger analysis of EH paths, but I always think about it in terms of supporting simplification of the normal control flow path. Consider unique_ptr: void f() { std::unique_ptr<int> p(new int(42)); g(p.get()); } This representation should support removing the heap allocation here by inlining the destructor on the normal path and EH path and promoting the heap allocation to a stack allocation. If our representation required early outlining, this would not be possible, or at least it would require inter-procedural analysis. That’s interesting.> > > > I wasn’t thinking about performance so much as code size in my original > comment. I’ve been looking at IR recently where code from multiple > exception handlers was combined while still maintaining the basic control > flow of the EH code. This kind of optimization is wreaking havoc for our > current MSVC compatible EH implementation (hence the redesign), but I guess > the Itanium ABI scheme doesn’t have a problem with it. > > > > I suppose that is closely related to your concerns about inlining, I just > hadn’t made the connection. > > > > In theory the funclets should be able to share code blocks without any > problem. The entry and exit points are the critical parts that make them > funclets. I’m just not sure how we can get the optimization passes to > recognize this fact while still meeting the MSVC runtime constraints. > Reid’s proposal of separate catch blocks should help with that, but I’m > still not sure we’ll want to use this representation for targets that don’t > need it. >I think sharing code between funclets would require some extreme gymnastics to generate the right pdata and xdata, but I suppose it's not too different from what MSVC 2015 requires for coroutines. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150518/26c3b8b3/attachment.html>
Philip Reames
2015-Jun-18 01:18 UTC
[LLVMdev] New EH representation for MSVC compatibility
On 05/18/2015 04:36 PM, Kaylor, Andrew wrote:> > >optimizing EH codepaths is not usually performance critical. > > >>Leaving aside the rest of the thread, I feel the need to refute this > point in isolation. I've found that optimizing (usually simplifying > and eliminating) exception paths ends up being *extremely* important > for my workloads. Failing to optimize exception paths sufficiently > tends to indirectly hurt things like inlining for example. Any design > which starts with the assumption that optimizing exception paths isn't > important is going to be extremely problematic for me. > > That’s interesting. >Sorry for not responding here for so long.> > I wasn’t thinking about performance so much as code size in my > original comment. I’ve been looking at IR recently where code from > multiple exception handlers was combined while still maintaining the > basic control flow of the EH code. This kind of optimization is > wreaking havoc for our current MSVC compatible EH implementation > (hence the redesign), but I guess the Itanium ABI scheme doesn’t have > a problem with it. >Since I'm pretty sure I added at least one optimization to simplify cfg which sounds problematic for you, sorry! :)> > I suppose that is closely related to your concerns about inlining, I > just hadn’t made the connection. >The effect on inlining is that combining the exception handler blocks reduces the perceived cost to inline a function with lots of exceptional control flow. When you're coming from a language where *every* call is an invoke and you need some per function/frame code to recover/rethrow just about any exception (that's just an implementation detail), commoning exceptional control flow turns out to be rather important.> In theory the funclets should be able to share code blocks without any > problem. The entry and exit points are the critical parts that make > them funclets. I’m just not sure how we can get the optimization > passes to recognize this fact while still meeting the MSVC runtime > constraints. Reid’s proposal of separate catch blocks should help with > that, but I’m still not sure we’ll want to use this representation for > targets that don’t need it. >If you fundamentally need the funclets, I think that makes you incompatible with the optimizations we want to support for itanium and related ABIs. I have no problem with supporting both separately, though I am worried about how much maintenance burden that will create going forward. Since I haven't been following the thread closely, is there an updated summary of the original proposal available? I know that various parts I had concerns with (the unsplitable blocks for instance) got addressed, but I'm having trouble tracking all the changes in discussion. Even just a quick list of "and we changed X" would be helpful. Philip -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150617/8c4ccb4b/attachment.html>
Reid Kleckner
2015-Jun-18 16:22 UTC
[LLVMdev] New EH representation for MSVC compatibility
On Wed, Jun 17, 2015 at 6:18 PM, Philip Reames <listmail at philipreames.com> wrote:> Since I haven't been following the thread closely, is there an updated > summary of the original proposal available? I know that various parts I > had concerns with (the unsplitable blocks for instance) got addressed, but > I'm having trouble tracking all the changes in discussion. Even just a > quick list of "and we changed X" would be helpful. >We should do an updated summary, but I've been busy. We really do need to keep the unsplittable catchblocks, though. Fundamentally, what we have is control flow described by data. This proposal essentially adds LLVM instructions that model that data. We can't insert real instructions like loads and stores between EH dispatch table entries, so it's forbidden. We can compensate for all the other CFG merging operations after the fact by duplicating code, but it's really hard to pattern match back EH dispatch once it's been allowed to round trip through memory, phis, GVN, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150618/b4682288/attachment.html>
Possibly Parallel Threads
- [LLVMdev] New EH representation for MSVC compatibility
- [LLVMdev] RFC: New EH representation for MSVC compatibility
- [LLVMdev] New EH representation for MSVC compatibility
- [LLVMdev] RFC: New EH representation for MSVC compatibility
- [LLVMdev] New EH representation for MSVC compatibility