[LLVMdev] Post-RA scheduler and IssueWidth

[Max Kazakov]

Hi Andrew,

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.

BR

 m

On Fri, May 27, 2011 at 1:54 PM, Andrew Trick <atrick at apple.com> wrote:
> 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PostRAIssueWidth.patch
Type: application/octet-stream
Size: 797 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110527/2ae78df4/attachment.obj>