This is an archive of the discontinued LLVM Phabricator instance.

[SEH] Implement filter capturing in CodeGen
ClosedPublic

Authored by rnk on Apr 3 2015, 4:04 PM.

Details

Summary

While capturing filters aren't very common, we'd like to outline
__finally blocks in the frontend to simplify -O0 EH preparation and
reduce code size. Finally blocks are usually have captures, and this is
the first step towards that.

Diff Detail

Event Timeline

rnk updated this revision to Diff 23242.Apr 3 2015, 4:04 PM
rnk retitled this revision from to [SEH] Implement filter capturing in CodeGen.
rnk updated this object.
rnk added a reviewer: majnemer.
rnk added a subscriber: Unknown Object (MLST).
majnemer added inline comments.Apr 3 2015, 5:06 PM
lib/CodeGen/CGException.cpp
1363–1364

Range-based for?

1409–1412

Why is this forbidden? Can't we just capture the address of the VLA?

rnk added inline comments.Apr 6 2015, 10:19 AM
lib/CodeGen/CGException.cpp
1363–1364

Hm, yeah, copy-pasta.

1409–1412

Filter outlining uses frameescape / framerecover to get access to the locals of the parent funciton. llvm.frameescape only supports static allocas. We would have to create a static alloca which contains the address of the VLA and then escape that, which is a pretty invasive change. It seemed better to punt on that for now and keep the patch smaller.

rnk updated this revision to Diff 23297.Apr 6 2015, 3:12 PM
  • Use foreach
majnemer accepted this revision.Apr 6 2015, 3:17 PM
majnemer edited edge metadata.

LGTM.

lib/CodeGen/CGException.cpp
95–97

Does this deserve a comment or have we documented this somewhere else?

This revision is now accepted and ready to land.Apr 6 2015, 3:17 PM
rnk added inline comments.Apr 6 2015, 3:23 PM
lib/CodeGen/CGException.cpp
95–97

Thanks, that probably deserves a comment.

My thinking was that this more closely mirrors the data that's actually available in the catch block, which is just the exception code in EAX/RAX.

This revision was automatically updated to reflect the committed changes.
rnk added a comment.Apr 6 2015, 5:13 PM

I ended up reverting the use of i32 for the landingpad value for now. It caused LLVM assertions later on in fastisel only and I couldn't debug it quickly.