This is the mail archive of the 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: 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
> block.

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 optimization should
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.

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