[LLVMdev] RFC: How to represent SEH (__try / __except) in LLVM IR

[Reid Kleckner]

On Wed, Dec 3, 2014 at 2:13 PM, Kaylor, Andrew <andrew.kaylor at intel.com>
wrote:

>  Hi Reid,
>
>
>
> I saw your patch but haven’t looked closely at it yet.
>
>
>
> I do have a work in progress for the outlining.  I expect to have
> something ready to share pretty soon, hopefully by the end of the week.  It
> won’t be ready for primetime, as it’s making a whole lot of assumptions
> about the structure of the IR, but I think it will work with a sample IR
> file based on what you posted in your earlier SEH review.  I expect that it
> will be a useful point of reference for discussion and that I should be
> able to quickly refactor it into something product ready once we’ve ironed
> out the expectations as to what the incoming IR will look like and how
> flexible the heuristics for identifying regions to outline need to be.
>

Nice. Sounds like I should move forward on the SEH patch, which assumes
that filters are pre-outlined, and move on to @llvm.outlined_handlers to
outlined __finally blocks next. Basically, teach CodeGen how to emit SEH
tables for IR that is already in the outlined form.


> One thing that I’ve discussed with a co-worker but haven’t explored in my
> implementation yet is the possibility of using CodeExtractor to do the
> outlining rather than basing it on the CloneFunction stuff.  My current
> implementation is based on CloneAndPruneFunctionInto as you suggested, but
> I wondered if CodeExtractor might not be a better starting point.  What do
> you think?
>

Hm, I wasn't aware of CodeExtractor. It looks like it basically reparents
basic blocks and fixes up the SSA graph. This is efficient, but I don't
think it will work if a BB is reachable by two landing pads. A BB can't be
extracted twice, but it can be cloned twice. Also, CodeExtractor can't
extract invokes. I would stick to cloning for now, and add extraction later
as an optimization.


> Also, at the moment I’m more or less ignoring the frame variable issue.
> My ValueMaterializer is just creating new allocas with the name I want.  I
> think that will be easy enough to patch up once your llvm.frameallocate
> stuff is in place.  The implication of this is that right now I’m not
> looking for live variables before I start outlining, I’m just picking them
> up as I go.  It seems like that may need to change.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141203/0dad470c/attachment.html>