Delay slot scheduling issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

In my architecture, there are two kinds of conditional branches, one
that can nullify (if not taken) and another that cannot.  Both have
two delay slots each and they can take any instruction other than a
call or a branch instruction.

The problem that I am facing is that at -O1, the delay slot scheduler
for a particular conditional branch is scheduling two instructions
before it into the delay slot.  Then it figures out that there is an
unconditional jump in the fall through path and the target of the
original conditional jump is right beyond the unconditional jump and
hence reverses the conditional jump to the target of the unconditional
one thereby removing the unconditional jump.  What it also does is to
reverse the setting of the INSN_FROM_TARGET_P for the two delay slot
instructions.  Now if the delay slot instructions were truly from the
target of the original branch or the fall through path, then this is a
valid change.  But in this case, since they are from before the
conditional jump, the change is logically incorrect.  Apparently
(according to the comment) this helps the mark_target_live_regs() to
handle the delay slot instructions correctly.  (reference in reorg.c
in function relax_delay_slots()).

Now, in order to identify when to generate a nullifying branch, I
check the following:

                   Either the INSN_ANNULLED_BRANCH_P is set for the
conditional branch
         OR
                   Both the delay slot instructions have the
INSN_FROM_TARGET_P set.

Now with this check, since the relax_delay_slots() has reversed the
INSN_FROM_TARGET_P for the delay slot instructions, I generate a
nullifying branch.  Since the delay slot instructions come from before
the conditional branch, my code generation is wrong when the program
takes the fall through path.

The question I am asking is that, is it right to always reverse the
INSN_FROM_TARGET_P in relax_delay_slots() when we are reversing a
branch?  I feel this should occur only if the instructions were either
from the target of the branch or from the fall through path.  But
definitely not if they are from before the branch.

How can we identify if they are from before the branch and not from
the fall through or the taken paths?

Thanks and regards
Ayonam


[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux