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.
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.
Thank you for explaining the situation. I also do understand that
introducing "pseudo" resource locked by all instructions will fix the
problem for 1-issue pipeline, but see it as a bit limiting for me at
the moment. Anyway, the patch is attached.
PostRAIssueWidth.patch (797 Bytes)