This is an archive of the discontinued LLVM Phabricator instance.

[WinEH] Add an EH registration and state insertion pass for 32-bit x86
ClosedPublic

Authored by rnk on Apr 30 2015, 3:57 PM.

Details

Summary

This pass is responsible for constructing the EH registration object
that gets linked into fs:00, which is all it does in this change. In the
future, it will also insert stores to update the EH state number.

I considered keeping this functionality in WinEHPrepare, but it's pretty
separable and X86 specific. It has conceptually very little to do with
the task of WinEHPrepare, which is currently outlining. WinEHPrepare is
also in theory useful on ARM, but this logic is pretty x86 specific.

Diff Detail

Repository
rL LLVM

Event Timeline

rnk updated this revision to Diff 24779.Apr 30 2015, 3:57 PM
rnk retitled this revision from to [WinEH] Add an EH registration and state insertion pass for 32-bit x86.
rnk updated this object.
rnk added reviewers: andrew.w.kaylor, majnemer.
rnk added a subscriber: Unknown Object (MLST).
majnemer edited edge metadata.Apr 30 2015, 4:48 PM

What ensures that control dependence will not be violated by SDAG? Should linkExceptionRegistration and unlinkExceptionRegistration use volatile loads and stores?

lib/Target/X86/X86WinEHState.cpp
132 ↗(On Diff #24779)

Debug leftovers?

143 ↗(On Diff #24779)

We could be more specific, I believe it is a PEXCEPTION_ROUTINE.

173 ↗(On Diff #24779)

clang-format?

181 ↗(On Diff #24779)

The other fields trailed with a ';', what format do you want to use?

197 ↗(On Diff #24779)

The other pseudo-types started with 'struct'. We should be consistent and have all of them or none of them start with it.

rnk added a comment.Apr 30 2015, 5:02 PM

What ensures that control dependence will not be violated by SDAG? Should linkExceptionRegistration and unlinkExceptionRegistration use volatile loads and stores?

First, today we don't support asynch EH, so any legal reordering of memory accesses within the block is fine. Second, if we do support asynch EH eventually, it will likely take the form of invoked intrinsics, which will have to deploy its own defense against load reordering. So, I don't think volatile is really necessary.

lib/Target/X86/X86WinEHState.cpp
143 ↗(On Diff #24779)

I deleted the extra type information because it felt like the comment was bloated.

rnk updated this revision to Diff 24783.Apr 30 2015, 5:02 PM
rnk edited edge metadata.
  • Add test which found some simple bugs
  • Fix some formatting issues
majnemer accepted this revision.May 1 2015, 11:35 AM
majnemer edited edge metadata.

LGTM

This revision is now accepted and ready to land.May 1 2015, 11:35 AM
This revision was automatically updated to reflect the committed changes.