This is the mail archive of the
mailing list for the GCC project.
Re: Delay branch scheduling vs. the CFG
- From: Joern RENNECKE <joern dot rennecke at st dot com>
- To: Jeffrey A Law <law at redhat dot com>
- Cc: Steven Bosscher <stevenb at suse dot de>, gcc at gcc dot gnu dot org
- Date: Wed, 16 Nov 2005 22:42:28 +0000
- Subject: Re: Delay branch scheduling vs. the CFG
> > > 4. An entirely new basic block on its own.
> > When can option 4 happen??
> IIRC it occurs when there was only 1 insn in either the target
> or fall-thru block. When it gets sucked into the delay
> slot of a branch, then it is effectively its own basic
When the fall-through is ended by a code label, and has only one insn,
and that is eligible for
a delay-slot which can be annulled-true, the fall-through block can end
up in the delay slot.
When the target block is ended by an unconditional jump, and otherwise
has only one insn,
which is elegible for a delay slot in preceding branch that can be
anulled-false, the fall-through
block can end up in the delay slot.
Likwise if the fall-through block consists only of a branch-delay-slot
eligible insn and
an unconditional jump, the branch and fall-through block can be
converted into an inverted
branch with anulled-false delay slot insn.
And finally, sometimes earlier reorg changes have changed the data flow
so that actually
no anulled slots are required (if there were no changes before, jump
have caught these opportunities, placing the lone insn in front of the
branch); or the only
data anti-dependency might have the branch condition itself.