Questions about selective scheduler and PowerPC
Andrey Belevantsev
abel@ispras.ru
Tue Oct 19 14:16:00 GMT 2010
On 19.10.2010 17:57, Jie Zhang wrote:
> 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.
I agree that ISSUE_POINTS can be removed, as it was not used (maybe Maxim
can comment more on this). However, the assert is not about the points but
exactly about the situation when a target is lying to the compiler about
its issue rate.
The ideal situation is that we agree on that this should never happen, but
then you need to fix all targets that use this trick, and it seems that
there is at least mips, ppc, and x86-64 (which is why I pointed you to
45352). The fix would be to find out why claiming the true issue rate
degrades performance and to implement the proper scheduling hooks for
changing priority of some insns, or to enable -fsched-pressure for the
offending targets.
This is a lot of work, which is why this assert was installed in max_issue
for relatively short amount of time. Maybe it's time to try again, but
let's have a consensus first that this assert should never trigger by
design and we have enough flexibility in the scheduler to provide legal
means to achieve the same performance effect.
Andrey
>
> /* ??? 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. */
>
>
More information about the Gcc
mailing list