llvm dev - May 2011 - [LLVMdev] Post-RA scheduler and IssueWidth

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

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

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>