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>
Joseph Tremoulet
2015-Jul-01 21:10 UTC
[LLVMdev] New EH representation for MSVC compatibility
Hi, I'd be interested in an updated summary as well, especially any thoughts you have on when the various pieces might come online and where extra hands could be helpful; we're eager to build our EH support in LLILC on top of this. Thanks -Joseph From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Reid Kleckner Sent: Thursday, June 18, 2015 12:22 PM To: Philip Reames Cc: Nick Lewycky; LLVM Developers Mailing List Subject: Re: [LLVMdev] New EH representation for MSVC compatibility On Wed, Jun 17, 2015 at 6:18 PM, Philip Reames <listmail at philipreames.com<mailto: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/20150701/2157c796/attachment.html>
David Majnemer
2015-Jul-01 23:42 UTC
[LLVMdev] New EH representation for MSVC compatibility
On Wed, Jul 1, 2015 at 2:10 PM, Joseph Tremoulet <jotrem at microsoft.com> wrote:> Hi, > > > > I'd be interested in an updated summary as well, especially any thoughts > you have on when the various pieces might come online and where extra hands > could be helpful; we're eager to build our EH support in LLILC on top of > this. >A preliminary step was to push personality routines off of LandingPadInst and onto functions, this is already in trunk. On the IR front, we ended up with the following set of instructions: catcblock, catchret, cleanupblock, cleanupret, terminateblock Of these, I've locally added basic support for catchblock, catchret and cleanupret. I'm working on cleanupblock and terminateblock as we speak. We'll still need to hook up CodeGenPrep and SDAG up to the new representation. Extra hands will be appreciated auditing LLVM's optimizations to ensure that they do not miscompile in the face of our new instructions.> > Thanks > > -Joseph > > > > > > *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On > Behalf Of *Reid Kleckner > *Sent:* Thursday, June 18, 2015 12:22 PM > *To:* Philip Reames > *Cc:* Nick Lewycky; LLVM Developers Mailing List > *Subject:* Re: [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. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150701/90e5e463/attachment.html>
Reasonably Related Threads
- [LLVMdev] New EH representation for MSVC compatibility
- [LLVMdev] New EH representation for MSVC compatibility
- [LLVMdev] RFC: New EH representation for MSVC compatibility
- [LLVMdev] RFC: New EH representation for MSVC compatibility
- [LLVMdev] RFC: New EH representation for MSVC compatibility