On 5/23/06, DJ Delorie [EMAIL PROTECTED] wrote:
What seems to happen is, we delete the simple jump even if we can't
fallthru, and thus the blocks get rearranged in an incorrect order.
Is there a bug here, or am I misunderstanding how this code works?
You're misunderstanding how this code
On 5/23/06, Steven Bosscher [EMAIL PROTECTED] wrote:
On 5/23/06, DJ Delorie [EMAIL PROTECTED] wrote:
What seems to happen is, we delete the simple jump even if we can't
fallthru, and thus the blocks get rearranged in an incorrect order.
Is there a bug here, or am I misunderstanding how this
You're misunderstanding how this code works. In cfglayout mode,
there is no order in the basic blocks such that
BLOCK_FOR_INSN(NEXT_INSN(BB_END(BB)) ) == BB-next_bb. This means
that you can fall through to other blocks than next_bb.
Thanks for the tip, I figured out what was really
On 5/23/06, DJ Delorie [EMAIL PROTECTED] wrote:
You're misunderstanding how this code works. In cfglayout mode,
there is no order in the basic blocks such that
BLOCK_FOR_INSN(NEXT_INSN(BB_END(BB)) ) == BB-next_bb. This means
that you can fall through to other blocks than next_bb.
Thanks
Sounds like you need a memory clobber constraint on the asm... ?
Yup, that looks like it would do the trick. Thanks!
On 5/23/06, DJ Delorie [EMAIL PROTECTED] wrote:
You're misunderstanding how this code works. In cfglayout mode,
there is no order in the basic blocks such that
BLOCK_FOR_INSN(NEXT_INSN(BB_END(BB)) ) == BB-next_bb. This means
that you can fall through to other blocks than next_bb.
I've got a case where an unconditional simple jump is being removed,
yet it doesn't jump to the next insn. The code in question seems
suspect...
Here we force CLEANUP_CFGLAYOUT true:
void
cfg_layout_initialize (unsigned int flags)
{
. . .
cleanup_cfg (CLEANUP_CFGLAYOUT | flags);
}
in
