This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fwd: [PATCH] Scheduling result adjustment to enable macro-fusion


On Mon, Nov 25, 2013 at 2:12 PM, Jeff Law <law@redhat.com> wrote:
>
>>
>> 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?
>
> True, it would be safe, but it seems inconsistent and confusing that some
> SCHED_GROUP_P references would be purged and others remain.
>
> Given SCHED_GROUP_P is to used strictly in the scheduler ISTM that we should
> be wiping it as we leave and that our RTL checkers ought to be verifying
> there are no insns with SCHED_GROUP_P left on.
>

How about add a verifier TODO_verify_sched_group_flag similar as
TODO_verify_rtl_sharing, and add the verifier in the todo lists of all
the scheduling passes.

>
>>
>> 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.
>
> Well, that's where I'd suggest focusing attention.
>
> jeff
>

After looking it carefully, even for sched1 and sched2, it is not ok
to depend on move_insn in commit_schedule to clean up all the
SCHED_GROUP_P, suppose a block is decided not to be scheduled by
dbg_cnt, then SCHED_GROUP_P inside the block will not be cleaned.
It is even more difficult to find a place inside SMS scheduling to do
the cleanup.

Any suggestions?

Thanks,
Wei.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]