On Sat, Apr 12, 2008 at 12:13 AM, Jim Wilson <[EMAIL PROTECTED]> wrote: > Mohamed Shafi wrote: > > > This looks like reordering is proper. When schedule-insn2 is run for > > the above region/block the no:of instructions in the region > > (rgn_n_insns) is 3. > > > > Maybe bb reorder got the basic block structure wrong, and the barrier is > not supposed to be part of the basic block. In fact, looking at > bb-reorder.c, I see this > /* Make BB_END for cur_bb be the jump instruction (NOT the > barrier instruction at the end of the sequence...). */ > > BB_END (cur_bb) = jump_insn; > Maybe it is getting this wrong someplace else in the file. This might > already be fixed in current sources, so you could try looking for an > existing patch to fix it. >
Thank you for your reply. Well i tracked down the cause to the md file. In the md file i had a define_expand for the jump pattern. Inside the pattern i was checking whether the value of the offset for the jump is out of range and if its out of range then force the offset into a register and emit indirect_jump. Though this didnt work, every time an unconditional jump was being emitted a barrier was also being emitted. It looks like in define_expand for jump we should consider all the case and emit DONE for all the cases, if you are considering any case, otherwise a barrier will be generated for cases not covered in DONE. Am i right? The following link is the reply from Ian for a query of mine regarding scheduling. http://gcc.gnu.org/ml/gcc/2008-04/msg00245.html After reading this, i feel that gcc should have looked for barrier insn while scheduling and should have given an ICE if it found one. True, barrier got into the instruction stream because of my mistake, but then thats what ICEs are for. Then again i might be wrong about this. Thanks for your time. Regards, Shafi P.S. I am still searching for a solution to choose between jump and indirect_jump pattern when the offset is out of range. http://gcc.gnu.org/ml/gcc/2008-04/msg00290.html May be you can help with that
