This is an archive of the discontinued LLVM Phabricator instance.

[WinEH] Move WinEHFuncInfo from MachineModuleInfo to MachineFunction
ClosedPublic

Authored by rnk on Nov 13 2015, 3:46 PM.

Details

Summary

Now that there is a one-to-one mapping from MachineFunction to
WinEHFuncInfo, we don't need to use a DenseMap to select the right
WinEHFuncInfo for the current funclet.

The main challenge here is that X86WinEHStatePass is an IR pass that
doesn't have access to the MachineFunction. I gave it its own
WinEHFuncInfo object that it uses to calculate state numbers, which it
then throws away. As long as nobody creates or removes EH pads between
this pass and SDAG construction, we will get the same state numbers.

The other thing X86WinEHStatePass does is to mark the EH registration
node. Instead of communicating which alloca was the registration through
WinEHFuncInfo, I added the llvm.x86.seh.ehregnode intrinsic. This
intrinsic generates no code and simply marks the alloca in use.

Diff Detail

Repository
rL LLVM

Event Timeline

rnk updated this revision to Diff 40183.Nov 13 2015, 3:46 PM
rnk retitled this revision from to [WinEH] Move WinEHFuncInfo from MachineModuleInfo to MachineFunction.
rnk updated this object.
rnk added a reviewer: majnemer.
rnk added a subscriber: llvm-commits.
JosephTremoulet accepted this revision.Nov 13 2015, 5:16 PM
JosephTremoulet edited edge metadata.

LGTM, nice cleanup. Is there somewhere that "don't creates or removes EH pads between state pass and SDAG construction" should be documented as a comment?

Looking at this and thinking about the CLR's use of funclets on non-Windows platforms makes me want to rename all these WinEH constructs to FuncletEH, like we did with isFuncletEHPersonality, but really that's orthogonal to this change.

This revision is now accepted and ready to land.Nov 13 2015, 5:16 PM
rnk added a comment.Nov 16 2015, 1:50 PM

LGTM, nice cleanup. Is there somewhere that "don't creates or removes EH pads between state pass and SDAG construction" should be documented as a comment?

I'll put something in X86WinEHStatePass. If this ends up being a problem, there's a clear path towards fixing it, but it requires a lot of extra work that will need to be redone with the new pass manager. We'd probably create a new ImmutablePass like MachineModuleInfo.

Looking at this and thinking about the CLR's use of funclets on non-Windows platforms makes me want to rename all these WinEH constructs to FuncletEH, like we did with isFuncletEHPersonality, but really that's orthogonal to this change.

I agree. WinEHFuncInfo is not a good name for our bag of EH data structures. EHFuncletInfo? EHFuncletStates? EHFuncletTables?

WinEHFuncInfo is not a good name for our bag of EH data structures. EHFuncletInfo? EHFuncletStates? EHFuncletTables?

I don't feel too strongly here, but

  • I like "_Info" since, as you say, it's a bag of data structures, and suffixing such things with Info seems to be fairly common in LLVM
  • I like the term "Funclet EH" as a generic replacement for "Windows EH".

So something like:

  • WinEHFuncInfo -> FuncletEHInfo
  • WinEHStatePass -> FuncletEHStatePass
  • WinEHHandlerType -> ??? This one is just used for C++, right? MSVCXXHandlerType?
  • WinEHTryBlockMapEntry -> FuncletTryMapEntry (dropped "EH" and "Block" just because it's such a mouthful)
  • WinEHPrepare -> FuncletEHPrepare (though since this does now just get invoked for Windows targets, it may make sense to leave its name alone until that changes)

?

This revision was automatically updated to reflect the committed changes.