This is an archive of the discontinued LLVM Phabricator instance.

MIR: Serialize a few bool function fields
ClosedPublic

Authored by arsenm on Apr 15 2022, 10:08 AM.

Details

Diff Detail

Event Timeline

arsenm created this revision.Apr 15 2022, 10:08 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 15 2022, 10:08 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
arsenm requested review of this revision.Apr 15 2022, 10:08 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 15 2022, 10:08 AM
Herald added a subscriber: wdng. · View Herald Transcript

Do you know whether we could compute their values instead? If the data can be derived by analyzing the function then we can add it to MIRParserImpl::computeFunctionProperties to compute them instead of explicitly serializing them.

Do you know whether we could compute their values instead? If the data can be derived by analyzing the function then we can add it to MIRParserImpl::computeFunctionProperties to compute them instead of explicitly serializing them.

CallsUnwindInit tracks a call to an IR intrinsic which is immediately discarded, so no.

For HasEHScopes, HasEHFunclets, and HasOpaqueSPAdjustment, I don't think so. It's set directly from the IR (and I think it's better to avoid as many backlinks there as possible).

For HasEHCatchret, it would require some kind of target knowledge to know what they selected ISD::CATCHRET to.

MatzeB accepted this revision.EditedApr 15 2022, 10:31 AM

At a first glance:

  • HasEHFunclets and HasEHScopes both seem to be true iff there's an EHPad basic block which should be testable with MBB.isEHPad? Admittedly I don't understand why those two variables, it seems we only ever set them both in FunctionLoweringInfo::set...
  • I guess CallsUnwind, CallsEHReturn, HasEHCatchret has no easy/obvious way to compute since patterns vary by target once things are lowered.

So yeah I think computing Funclets/Scopes is worth a try unless I am missing something.

Either way this change LGTM

This revision is now accepted and ready to land.Apr 15 2022, 10:31 AM

At a first glance:

  • HasEHFunclets and HasEHScopes both seem to be true iff there's an EHPad basic block which should be testable with MBB.isEHPad? Admittedly I don't understand why those two variables, it seems we only ever set them both in FunctionLoweringInfo::set...

But it's set conditionally based on isa<LandingPadInst>(BB.getFirstNonPHI()), so EHPad doesn't necessarily imply them (but I have no understanding of how this exception stuff is supposed to work)

At a first glance:

  • HasEHFunclets and HasEHScopes both seem to be true iff there's an EHPad basic block which should be testable with MBB.isEHPad? Admittedly I don't understand why those two variables, it seems we only ever set them both in FunctionLoweringInfo::set...

But it's set conditionally based on isa<LandingPadInst>(BB.getFirstNonPHI()), so EHPad doesn't necessarily imply them (but I have no understanding of how this exception stuff is supposed to work)

I don't really have experience with EH either. So let's go ahead with the patch as-is then.

rnk accepted this revision.Apr 15 2022, 12:47 PM

lgtm

It might be possible to recompute these, but I don't think it would be reliable.