[AIEX] NFC: Refactor Alternate Descriptor codebase

[krishnamtibrewala]

No description provided.

[gbossu]

I'm starting to wonder how far we should go with adding more layers in the schedule. I'd say we need to go even further. Our interfaces to the HazardRecognizer are becoming painful to work with. I'd like group together what is really needed to make a correct scheduling decision. I'd say at this point we need something like:

struct DynamicMIDescriptor {
  ArrayRef<InstrStage> ItinStages;
  SlotBits SlotSet,
  MemoryBankBits MemoryBanks,
  SmallVector<int, 2> MemoryAccessCycles
};

Then we could just pass that dynamic descriptor to the checkHazard/enterResources methods of the HazardRecognizer. Within the scheduler, we could easily retrieve that dynamic descriptor by doing something like AlternateDescrMap->getDynamicDescr(MI), and that would find the right itinerary, slotset, etc. all based on the selected opcode (or the standard one).

I don't think we should do that change just now, and I can also work on this, but I'd like to start the discussion. What do you think @martien-de-jong @krishnamtibrewala @andcarminati ?

[martien-de-jong]

I'm starting to wonder how far we should go with adding more layers in the schedule. I'd say we need to go even further. Our interfaces to the HazardRecognizer are becoming painful to work with. I'd like group together what is really needed to make a correct scheduling decision. I'd say at this point we need something like:

struct DynamicMIDescriptor {
  ArrayRef<InstrStage> ItinStages;
  SlotBits SlotSet,
  MemoryBankBits MemoryBanks,
  SmallVector<int, 2> MemoryAccessCycles
};

Then we could just pass that dynamic descriptor to the checkHazard/enterResources methods of the HazardRecognizer. Within the scheduler, we could easily retrieve that dynamic descriptor by doing something like AlternateDescrMap->getDynamicDescr(MI), and that would find the right itinerary, slotset, etc. all based on the selected opcode (or the standard one).

I don't think we should do that change just now, and I can also work on this, but I'd like to start the discussion. What do you think @martien-de-jong @krishnamtibrewala @andcarminati ?

That looks good. I would then also like a constructor for this that takes a MachineInstr. I can also imagine that we grab the static part of this and let tablegen generate it.

[gbossu]

That looks good, except that all of this is static, not dynamic ;-)

Fair enough 😆 I thought of dynamic as in "the scheduling descriptor is determined based on the selected opcode, and operands". Those things can change throughout the compilation process. Maybe you can think of a better qualifier than "dynamic"? Maybe "FullyQualifiedDescr"?

[martien-de-jong]

That looks good, except that all of this is static, not dynamic ;-)

Fair enough 😆 I thought of dynamic as in "the scheduling descriptor is determined based on the selected opcode, and operands". Those things can change throughout the compilation process. Maybe you can think of a better qualifier than "dynamic"? Maybe "FullyQualifiedDescr"?

I guess that MemoryBanks is dynamic

[andcarminati]

I'm starting to wonder how far we should go with adding more layers in the schedule. I'd say we need to go even further. Our interfaces to the HazardRecognizer are becoming painful to work with. I'd like group together what is really needed to make a correct scheduling decision. I'd say at this point we need something like:

struct DynamicMIDescriptor {
  ArrayRef<InstrStage> ItinStages;
  SlotBits SlotSet,
  MemoryBankBits MemoryBanks,
  SmallVector<int, 2> MemoryAccessCycles
};

Then we could just pass that dynamic descriptor to the checkHazard/enterResources methods of the HazardRecognizer. Within the scheduler, we could easily retrieve that dynamic descriptor by doing something like AlternateDescrMap->getDynamicDescr(MI), and that would find the right itinerary, slotset, etc. all based on the selected opcode (or the standard one).

I don't think we should do that change just now, and I can also work on this, but I'd like to start the discussion. What do you think @martien-de-jong @krishnamtibrewala @andcarminati ?

I agree that HR is handling several different interfaces now and this redesign will help to concentrate all the information that is related to one specific instruction. We can put this on our backlog for sure.

[gbossu]

LGTM