It is needed for target specific initializatons.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Hi @cdevadas,
What do you want to achieve with this call back?
It feels wrong to me that the TargetMachine would need to know about the MRI. IIRC, the TargetMachine holds information that applies to the whole target and doesn't do any specific based on each function. (At least it doesn't hold any state.)
Cheers,
-Quentin
The TargetMachine doesn't maintain state but manages the construction of MachineFunctionInfo and MIR parsing. This change is the consequence of your suggestion to use the callbacks for virtual registers (D134950) instead of the directly tracking virtual register flags in MRI. If we have to handle this in a side table stored in MFI, the TargetMachine needs to register these callbacks at the same time MFI is constructed (which is here).
I see, you need to hook up the delegate registration.
Make sense.
Let me think about it.
If anything we probably need better comments to make it more obvious what the purpose of this callback is.
I'll get back to you.
Sorry for the delay I don't have an answer, but I have a couple of questions:
- Would it work to attach the delegate in MachineFunction::initTargetMachineFunctionInfo?
- Do we want to support MachineFunction/Info cloning?
For #1 I guess it depends whether or not we want to offer a more general hook point than just MachineFunctionInfo.
I am guessing we want to support #2, and #1 doesn't work for that and neither is the current patch. We probably want to add a call to this hook during ::clone.
Anyhow, I am willing to go with the current patch if we add an actual use case in this patch. I'd like that we have an example that goes in at the same time as we introduce registerMachineRegisterCallback.
Probably
- Do we want to support MachineFunction/Info cloning?
This has to work and needs to be serializable.
For #1 I guess it depends whether or not we want to offer a more general hook point than just MachineFunctionInfo.
I am guessing we want to support #2, and #1 doesn't work for that and neither is the current patch. We probably want to add a call to this hook during ::clone.Anyhow, I am willing to go with the current patch if we add an actual use case in this patch. I'd like that we have an example that goes in at the same time as we introduce registerMachineRegisterCallback.
I strongly think this should be kept separate. The actual use patch is much larger and conceptually detached.
Do we want to support MachineFunction/Info cloning?
This has to work and needs to be serializable.
What's the plan to support that?
I strongly think this should be kept separate. The actual use patch is much larger and conceptually detached.
Fair enough, I was hoping for something small.