[LLVMdev] New EH representation for MSVC compatibility

David Majnemer david.majnemer at gmail.com
Wed Jul 1 16:42:56 PDT 2015


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>


More information about the llvm-dev mailing list