This is the mail archive of the
mailing list for the GCC project.
Re: Finding insns to reorder using dataflow
- From: Kyrill Tkachov <kyrylo dot tkachov at arm dot com>
- To: Jeff Law <law at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Fri, 14 Aug 2015 10:05:56 +0100
- Subject: Re: Finding insns to reorder using dataflow
- Authentication-results: sourceware.org; auth=none
- References: <55CC7A43 dot 5010209 at arm dot com> <55CCC3E2 dot 3030003 at redhat dot com>
On 13/08/15 17:20, Jeff Law wrote:
On 08/13/2015 05:06 AM, Kyrill Tkachov wrote:
I'm implementing a target-specific reorg pass, and one thing that I want
is for a given insn in the stream to find an instruction
in the stream that I can swap it with, without violating any dataflow
The candidate instruction could be earlier or later in the stream.
I'm stuck on finding an approach to do this. It seems that using some of
infrastructure is the right way to go, but I can't figure out the details.
can_move_insns_across looks like relevant, but it looks too heavyweight
with quite a lot
I suppose somehow constructing regions of interchangeable instructions
would be the way
to go, but I'm not sure how clean/cheap that would be outside the scheduler
Any ideas would be appreciated.
I think you want all the dependency analysis done by the scheduler.
Which leads to the question, can you model what you're trying to do in
the various scheduler hooks -- in particular walking through the ready
list seems appropriate.
The problem I'm trying to solve can be expressed in this way:
"An insn that satisfies predicate pred_p (insn) cannot appear exactly N insns
apart from another insn 'insn2' that satisfies pred_p (insn2). N is a constant".
So, the problem here is that this restriction is not something expressed in terms
of cycles or DFA states, but rather distance in the instruction stream.
I don't think I can do this reliably during sched2 because there is still splitting
that can be done that will create more insns that will invalidate any book keeping
that I do there.
However, during TARGET_MACHINE_DEPENDENT_REORG I can first split all insns and then
call schedule_insns () to do another round of scheduling. However, I'm a bit confused
by all the different scheduler hooks and when each one is called in relation to
I'd need to keep some kind of bitfield recording for the previous N instructions in
the stream whether they satisfy pred_p. Where would I record that?
Can I just do everything in TARGET_SCHED_REORDER? i.e.
given a ready list check that no pred_p insns in it appear N insns apart from
another such insn (using my bitfield as a lookup helper), reorder insns as
appropriate and then record the order of the pred_p insns in the bitfield.
Would the scheduler respect the order of the insns that was set by TARGET_SCHED_REORDER
and not do any further reordering?