This is an archive of the discontinued LLVM Phabricator instance.

Check if register class was changed in constrainOperandRegClass()
ClosedPublic

Authored by wvoquine on Mar 28 2022, 2:16 PM.

Details

Summary

NFC
When no actual change happens there's no need to notify the
observers about the fact the register class is being constrained.
So we should avoid notifying observers when no change has
happened, because this can dramatically affect compile
time for particular test cases.

Diff Detail

Event Timeline

wvoquine created this revision.Mar 28 2022, 2:16 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 28 2022, 2:16 PM
Herald added a subscriber: hiraditya. · View Herald Transcript
wvoquine requested review of this revision.Mar 28 2022, 2:16 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 28 2022, 2:16 PM
wvoquine edited the summary of this revision. (Show Details)Mar 28 2022, 2:31 PM
dsanders added inline comments.Mar 28 2022, 2:38 PM
llvm/lib/CodeGen/GlobalISel/Utils.cpp
61–65

I'm not keen on duplicating internals of constrainRegToClass() behaviour (even obvious behaviours like this one). Do you get a similar perf fix if you check between the possible change and the notification with something like this?:

auto *OldRegClass = MRI.getRegClassOrNull(Reg);
Register ConstrainedReg = constrainRegToClass(MRI, TII, RBI, Reg, RegClass);
if (ConstrainedReg != Reg) {
  insert copy
  notify observers
} else {
  auto *NewRegClass = MRI.getRegClassOrNull(Reg);
  if (OldRegClass != &NewRegClass) {
    notify observers
  }
}
97

It's not for this patch but this call is supposed to happen before the change. It won't work properly for all observers if it's after the change. For example, the debug location info checking one will compare the state after the change to the state after the change with this call where it currently is.

wvoquine added inline comments.Mar 28 2022, 3:10 PM
llvm/lib/CodeGen/GlobalISel/Utils.cpp
61–65

We discussed that issue with Daniel separately. It looks like a viable approach could be to add API calls RBI.needToConstrainGenericRegister()->MRI. needToConstrainGenericRegister()->...
And the implementation of those calls would be involved in the corresponding check within chain of calls of constrainRegToClass() - so that we would be checking precisely the same way as the function imposing the constraints.

wvoquine updated this revision to Diff 418748.Mar 28 2022, 6:04 PM
wvoquine edited the summary of this revision. (Show Details)
wvoquine marked an inline comment as done.
arsenm added inline comments.Mar 30 2022, 1:10 PM
llvm/include/llvm/CodeGen/RegisterBankInfo.h
644 ↗(On Diff #418748)

I don't see the point of having this be both a separate utility function and a static member. It should be either one or the other

llvm/lib/CodeGen/GlobalISel/Utils.cpp
46

Why call a static method through RBI?

wvoquine added inline comments.Mar 30 2022, 1:39 PM
llvm/include/llvm/CodeGen/RegisterBankInfo.h
644 ↗(On Diff #418748)

I just followed the choices made for the corresponding utility functions/methods for constrainGenericRegister() and constrainOperandRegClass().

There's no actual need for the latter to be around at the moment, I can remove the utility function.

llvm/lib/CodeGen/GlobalISel/Utils.cpp
46

Good point!
By the way, the same would apply to the llvm::constrainRegToClass() implementation below... I just replicated that sort of code without noticing it was actually a static method.

I guess, it really makes sense to remove this utility method right now, to avoid fixing the API some of the operands of which are not required...

wvoquine added inline comments.Mar 30 2022, 1:40 PM
llvm/include/llvm/CodeGen/RegisterBankInfo.h
644 ↗(On Diff #418748)

There's no actual need for the latter

I mean, there's no real need for needToConstrainRegToClass() at the moment.

dsanders added inline comments.Mar 30 2022, 2:32 PM
llvm/lib/CodeGen/MachineRegisterInfo.cpp
82 ↗(On Diff #418748)

This is more of a naming nitpick but this path isn't constraining the reg class yet constraining is still needed. I believe the caller is expected to emit a copy instead and that caller should notify the observers correctly

FWIW, MinNumRegs is hardly ever used, I can only find a couple instances

llvm/lib/CodeGen/RegisterBankInfo.cpp
131–132 ↗(On Diff #418748)

There's also a chance it isn't and constrainGenericRegister() changes the class requiring that the observers be notified

wvoquine added inline comments.Mar 30 2022, 2:50 PM
llvm/lib/CodeGen/MachineRegisterInfo.cpp
82 ↗(On Diff #418748)

Maybe I should call needsConstrainOrCopy() ?

llvm/lib/CodeGen/RegisterBankInfo.cpp
131–132 ↗(On Diff #418748)

You mean, it's not constrained appropriately but the Reg's class is the same?

wvoquine marked an inline comment as not done.Mar 31 2022, 11:06 AM
wvoquine added inline comments.
llvm/lib/CodeGen/GlobalISel/Utils.cpp
61–65

After further discussion of the new patch, it turns out the post-check @dsanders has proposed would be the right way to go. The reasons are

  1. The proposed API doesn't fully solve the pre-check problem anyway, so would still be an ad hoc solution.
  2. To make it less ad hoc the function needToConstrainRegToClass() would need to be saying if a register class change is actually going to happen in the constrainRegToClass() call. And I personally don't see a good name for such a function.
  3. A better approach would be to pass the observers to constrainRegToClass() but that would be a large interface change.

So, considering all this I'm leaning towards the proposed "post-check" suggestion with a "TODO:" about a solution which would be not an ad hoc one.

wvoquine updated this revision to Diff 419535.Mar 31 2022, 12:15 PM
wvoquine retitled this revision from Early return in constrainOperandRegClass() to Check if register class was changed in constrainOperandRegClass().
wvoquine edited the summary of this revision. (Show Details)

Went ahead with the post-check Daniel proposed.
This is a cleaner approach - we just check whether the register class has changed as a part of the constraining and based on that decide whether we need to notify the observers.

wvoquine marked an inline comment as done.Mar 31 2022, 12:16 PM
arsenm accepted this revision.Mar 31 2022, 12:27 PM
This revision is now accepted and ready to land.Mar 31 2022, 12:27 PM

Thanks for accepting!

Could anyone, please, submit the change?

This revision was landed with ongoing or failed builds.Apr 5 2022, 11:55 AM
This revision was automatically updated to reflect the committed changes.