This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fwd: [PATCH] Scheduling result adjustment to enable macro-fusion
- From: Wei Mi <wmi at google dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, Jan Hubicka <hubicka at ucw dot cz>, Alexander Monakov <amonakov at ispras dot ru>, Steven Bosscher <stevenb dot gcc at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, David Li <davidxl at google dot com>, Kirill Yukhin <kirill dot yukhin at gmail dot com>, Vladimir Makarov <vmakarov at redhat dot com>
- Date: Mon, 25 Nov 2013 11:48:18 -0800
- Subject: Re: Fwd: [PATCH] Scheduling result adjustment to enable macro-fusion
- Authentication-results: sourceware.org; auth=none
- References: <CA+4CFy7TCbnm3irCTKYuQmsz_xPNbC3YmugHC6fjiewPcREzZA at mail dot gmail dot com> <CAMe9rOqLzrsxkfbSLqT29cntdJ_8PURh2NRmoLzQKM5Fzv8BEQ at mail dot gmail dot com> <20130924212516 dot GA11364 at kam dot mff dot cuni dot cz> <CA+4CFy6JTOSgOWwk+cySMaopg+qxcMn=A=L-MQoYK4MVb5FkAg at mail dot gmail dot com> <CA+4CFy6vGb__5DiT+jjYSSCpPCg0a+z2ueqg=0OQA9=E0=WrLw at mail dot gmail dot com> <525DA6FF dot 5010901 at redhat dot com> <CA+4CFy5qXcZz4CVshVjk8AwEu=B-Spctag+KSo+Ue5pgAvxR8Q at mail dot gmail dot com> <525EF180 dot 4020708 at redhat dot com> <CA+4CFy4CuW=U=GDYipxRjtBdszHqxaS_pK4NeJKeNWT+W75Veg at mail dot gmail dot com> <CA+4CFy5K--mRx6k_+Aro8-_ENp+ye3=7PqZQQ4ph6m7MpxW9JA at mail dot gmail dot com> <20131104011801 dot GB32134 at atrey dot karlin dot mff dot cuni dot cz> <CA+4CFy6j-sRhUBTpBOZ=50mnESiYBDG64FiC-71ybDYVyFpC7Q at mail dot gmail dot com> <CAMe9rOqdWFmiqEOrpRJT_YiyvvGmQx-M4qGACMEvV6khyMyc3A at mail dot gmail dot com> <CA+4CFy74eA6arbvph8G1zMAXzDURx_E4NbRdeQXkbRLsOHnvRg at mail dot gmail dot com> <52939894 dot 9020005 at redhat dot com> <CA+4CFy4eTkdzsh=xFukjduXXRvg6OWhMb9MOafBqEjWQEhSg9Q at mail dot gmail dot com> <5293A434 dot 4000305 at redhat dot com>
On Mon, Nov 25, 2013 at 11:25 AM, Jeff Law <law@redhat.com> wrote:
> On 11/25/13 12:16, Wei Mi wrote:
>>>
>>>
>>> I'll note you're doing an extra pass over all the RTL here. Is there
>>> any
>>> clean way you can clean SCHED_GROUP_P without that extra pass over the
>>> RTL?
>>> Perhaps when the group actually gets scheduled?
>>>
>>> jeff
>>>
>>
>> With your help to understand that sched group will not be broken by
>> other passes in other cases, I can cleanup SCHED_GROUP_P for
>> macrofusion only by checking every condjump insn which is at the end
>> of BB. Then the cost will be in the same scale with bb nums. Do you
>> think it is ok?
>>
>> Thanks,
>> Wei.
>>
>> 2013-11-25 Wei Mi <wmi@google.com>
>>
>> PR rtl-optimization/59020
>> * haifa-sched.c (cleanup_sched_group): New function.
>> (sched_finish): Call cleanup_sched_group to cleanup
>> SCHED_GROUP_P.
>>
>> 2013-11-25 Wei Mi <wmi@google.com>
>> PR rtl-optimization/59020
>> * testsuite/gcc.dg/pr59020.c (void f):
>
> But there's nothing that requires the SCHED_GROUP_P to be at the end of a
> block. The cc0-setter/cc0-user case was just an example. Another example
> would be groups created around call insns on small register class machines.
>
Doing the cleanup at the end of BB could ensure all the groups
inserted for macrofusion will be cleaned. For groups not at the end of
a block, no matter whether they are cleaned up or not, nothing will
happen because other passes will not mess up those groups -- you said
cc0-setter/cc0-user was such a case. Is it call group a different
case?
> ISTM that when an insn moves from the ready list to back to the main insn
> chain, that you can just clear SCHED_GROUP_P at that time. Is that not the
> case?
>
> jeff
>
For sched1 and sched2, we can do that. Actually, I find it has been
done in move_insn when commit_schedule. But for modulo scheduling, I
havn't found a good place to do it.
Thanks,
Wei.