[LLVMdev] RFC: How to represent SEH (__try / __except) in LLVM IR
rnk at google.com
Wed Dec 3 15:13:09 PST 2014
On Wed, Dec 3, 2014 at 2:13 PM, Kaylor, Andrew <andrew.kaylor at intel.com>
> 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...
More information about the llvm-dev