[LLVMdev] scoreboard hazard det. and instruction groupings

[Andrew Trick]

On Jun 11, 2012, at 9:30 AM, Hal Finkel <hfinkel at anl.gov> wrote:

> I'm considering writing more-detailed itineraries for some PowerPC CPUs
> that use the 'traditional' instruction grouping scheme. In essence,
> this means that multiple instructions will stall in some pipeline stage
> until a complete group is formed, then all will continue.
> 
> I expect to provide CPU-specific code to help determine when the
> currently-waiting instructions would form a group. Is there a
> straightforward way that I could override the scoreboard hazard
> detector (or layer on top of it) to insert this kind of logic?
> 
> Should I instead be looking to do something like what Hexagon does
> for VLIW cores? I think the main difference between the PowerPC scheme
> and a VLIW scheme, is that the CPU itself can form groups internally,
> it is just more efficient if the groups are provided pre-made. Maybe
> this difference, if it is one, is insignificant.

Hal, I think you're asking whether to use the ScheduleHazardRecognizer or DFAPacketizer. I suggest sticking with the hazard recognizer unless you have an important problem that can't be solved that way. It's the API used by most targets and doesn't require a custom scheduler. Although I don't want to stop you from generalizing the DFA work either if you feel compelled to do that.

Ignoring compile time for a moment, I think an advantage of a DFA is modeling a situation where the hardware can assign resources to best fit the entire group rather then one instruction at a time. For example, if InstA requires either Unit0 or Unit1, and InstB requires Unit0, is {InstA, InstB} a valid group? Depending on your cpu, a DFA could either recognize that it's valid, or give you a chance to reorder the instructions within a group once they've been selected.

Ideally, you can express your constraints using InstrStage itinerary entries. If not, then you need to do your own bookkeeping by saving extra state during EmitInstruction and checking for hazards in getHazardType. At this point, you need to decide whether your custom logic can be easily generalized to either top-down or bottom-up scheduling. If not, you can force MISched to scheduling one either direction. SD scheduling is stuck with bottom-up for the remainder of its days, and postRA scheduling is top-down.

-Andy