[LLVMdev] New EH representation for MSVC compatibility

[Joseph Tremoulet]

> Extra hands will be appreciated auditing LLVM's optimizations to ensure that they do not miscompile in the face of our new instructions
thinking through what the output of that would be...  I suppose that for each relevant optimization, we'd want either a plausible explanation why it won't miscompile as-is, or a lit test demonstrating a miscompile (accompanied by a fix if small or a bug if large), is that the right idea?  Any particular optimization(s) I should start with?

> I look forward to these patches.  Please CC me as a reviewer
Likewise.


Thanks
-Joseph


From: Philip Reames [mailto:listmail at philipreames.com]
Sent: Thursday, July 2, 2015 8:25 PM
To: David Majnemer; Joseph Tremoulet
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] New EH representation for MSVC compatibility


On 07/01/2015 04:45 PM, David Majnemer wrote:


On Wed, Jul 1, 2015 at 4:42 PM, David Majnemer <david.majnemer at gmail.com<mailto:david.majnemer at gmail.com>> wrote:


On Wed, Jul 1, 2015 at 2:10 PM, Joseph Tremoulet <jotrem at microsoft.com<mailto: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.

And I forgot to mention: I hope to see the new instructions out for review by the end of the week.
I look forward to these patches.  Please CC me as a reviewer so that I see them; I'm a bit behind on commit traffic at the moment.

Please make sure the LangRef changes are reasonable complete when you post the patch.  The semantics will be the part I'm most concerned about.




Thanks
-Joseph


From: llvmdev-bounces at cs.uiuc.edu<mailto:llvmdev-bounces at cs.uiuc.edu> [mailto: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.

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu>         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev






_______________________________________________

LLVM Developers mailing list

LLVMdev at cs.uiuc.edu<mailto: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/20150708/59dbd32d/attachment.html>