Questions about selective scheduler and PowerPC

[Jie Zhang]

On 10/18/2010 03:41 PM, Andrey Belevantsev wrote:
> On 18.10.2010 11:31, Jie Zhang wrote:
>> Hi Andrey,
>>
>> On 10/18/2010 03:13 PM, Andrey Belevantsev wrote:
>>> Hi Jie,
>>>
>>> On 18.10.2010 10:49, Jie Zhang wrote:
>>>>
>>>> When this error happens, FENCE_ISSUED_INSNS (fence) is 2 and
>>>> issue_rate is
>>>> 1. PowerPC 8540 is capable to issue 2 instructions in one cycle, but
>>>> rs6000_issue_rate lies to scheduler that it can only issue 1
>>>> instruction
>>>> before register relocation is done. See the following code:
>>>
>>> See PR 45352. I've tried to fix this in the selective scheduler by
>>> modeling the lying behavior in line with the haifa scheduler. Let me
>>> know if the last patch from the PR audit trail doesn't work for you.
>>>
>>> In addition, after the above patch goes in, I can make the selective
>>> scheduler not try to jump through the hoops with putting correct sched
>>> cycles on insns for targets which don't need it in their target_finish
>>> hook. I guess powerpc needs this though, but x86-64 (for which PR 45342
>>> was opened) almost surely does not.
>>>
>> Thanks for your reply. I just tried. That patch does not help for this
>> issue.
> I see, I didn't touch the failing assert with the patch. Can you just
> remove the assert and see if that helps for you? I cannot think of how
> it can be relaxed and still be useful.
>
Removing the failing assert fixes the test case. But I wonder why not 
just get max_issue correct. I'm testing the attached patch. IMHO, 
max_issue looks confusing.

  * The concept of ISSUE POINT has never been used since the code landed 
in repository.

  * In the comment just before the function, it's mentioned that 
MAX_POINTS is the sum of points of all instructions in READY. But it 
does not match the code. The code only summarizes the points of the 
first MORE_ISSUE instructions. If later ISSUE_POINTS become not uniform, 
that piece of code should be redesigned.

So I think it's good to remove it now. And "top - choice_stack" is a 
good replacement for top->n. So we can remove field n from struct 
choice_entry, too.

Now I'm looking at MIPS target to find out why this change in the would 
cause PR37360.

    /* ??? We used to assert here that we never issue more insns than 
issue_rate.
       However, some targets (e.g. MIPS/SB1) claim lower issue rate than 
can be
       achieved to get better performance.  Until these targets are 
fixed to use
       scheduler hooks to manipulate insns priority instead, the assert 
should
-     be disabled.
-
-     gcc_assert (more_issue >= 0);  */
+     be disabled.  */


-- 
Jie Zhang
CodeSourcery
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc-max-issue-honor-issue-rate.diff
Type: text/x-patch
Size: 4542 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20101019/f6ebae42/attachment.bin>