[LLVMdev] Post-RA scheduler and IssueWidth

[Andrew Trick]

On May 26, 2011, at 7:29 PM, Max Kazakov wrote:

> Hi,
> 
> Can someone tell me if my understanding is right in that post-RA scheduler
> currently assumes no limits on a pipeline's issue width? If so, is it by design
> or just overlooked? I have a case for, say, 1-issue pipeline when certain
> pipeline resource becomes occupied a few clocks after instruction start, but
> hazard evaluation is done incorrectly as scheduler advances clock not for every
> (because of 1-issue) cycle but only when resource conflict happens (from its
> point of view) within the same cycle. It would be great if someone can help with
> explanations on how to make post-RA scheduler to take actual issue rate into
> account without modifying current LLVM sources. Otherwise, I have a (trivial)
> patch for it.
> 
> BR
> 
> m


Hi Max,

The target's processor itinerary is expressive enough to enforce issue width. See ARMScheduleXX.td. Several months ago, I added ARMSubTarget::computeIssueWidth() so clients could query issue width without modeling the complete reservation table (via ScoreboardHazardRecognizer). This function may or may not work with your itinerary--you may need to write your own. I did consider adding a separate issue width field to the target description for targets that didn't have an itinerary, but punted on that because I didn't want to maintain it for every microarchitecture given the dubious value.

Pre-RA-sched already checks issue width to avoid unnecessary calls to the hazard checker. The same could also be done in the post-RA-sched--it simply was never necessary. But if your patch does it cleanly I think we could take it.

It would be nice if the itinerary did not require defining "pseudo" functional unit to enforce issue width. But computeIssueWidth() currently depends on it. Catch-22.

-Andy