please go ahead.
Ljx,
Please help check that the change will not affect other targets since
SL has no extensive way to test.
Thx!
Sun

On Fri, Jan 14, 2011 at 11:34 AM, Gang Yu <yugang...@gmail.com> wrote:
> Hi,all
>
>    Can gatekeep help review this bug? It is a SL specifial bug, however, we
> plan to check the patch into open64 repository and it is general since other
> targets may also meet it if they do op substitutions.
>
>    The cut-down bug case is:
>
>    extern void* memcpy(void *, const void *, unsigned int);
>    etern unsigned int TRC_ITOA(unsigned int, unsigned char *, unsigned int);
>
>   void test_f(unsigned int num, unsigned char *buf, unsigned int len) {
>
>
>     unsigned int str_len = 0;
>     unsigned char tmp_buf[len+1];
>     str_len = TRC_ITOA(num, tmp_buf, 10);
>     memcpy(buf + len - str_len, tmp_buf, str_len);
>   }
>
>    SL features 16bit insns substitution  for those frequently used 32bit
> risc insns.  however, for this case, it will generate wrong code. SL5, our
> single issue processor will generate the following epilog BB code:
>
> .LBB3_test_f:
>
>     .loc    1    11    0
>  #  11  }
>     ldw $24,-24($30)                  # [0] gra_spill1
>     mv16 $sp,$30                      # [1]
>     mvtc16 ra,$24                     # [2]
>
>     ldw $7,-28($30)                   # [3] gra_spill2
>     mv16 $30,$7                       # [5]
>     ret16                             # [6]
>
> $sp is restored by $bp($30) before fetching the spilled $30 back. when
> interrupt happens, the stack is clobbered and then $30.
>
>
> This bug is caused by the substiton on the $sp adjust insn and forget to
> annotate it,
> so the scheduler could not find the sp adjust insn in the exit BB and it do
> aggressive scheduling.
>
> We suggest a patch for this bug:
>
>
> Index: osprey/be/cg/SL/disp_instr.cxx
> ===================================================================
> --- osprey/be/cg/SL/disp_instr.cxx      (revision 3461)
> +++ osprey/be/cg/SL/disp_instr.cxx      (working copy)
>
> @@ -123,6 +123,14 @@
>      Copy_WN_For_Memory_OP(newop, _cur_op);
>    }
>    BB_Insert_Op_Before(OP_bb(_cur_op), _cur_op, newop);
> +
> +  if (_cur_op == BB_entry_sp_adj_op(_cur_op->bb)) {
> +    Set_BB_entry_sp_adj_op(_cur_op->bb,newop);
>
> +  }
> +  if (_cur_op == BB_exit_sp_adj_op(_cur_op->bb)) {
> +    Set_BB_exit_sp_adj_op(_cur_op->bb,newop);
> +  }
> +
>    OP_Change_To_Noop(_cur_op);
>    _cur_op = newop;
>    return;
>
> after the patch, the sp adjust insn is not scheduled and the bug so fixed.
>
> .LBB3_test_f:
>
>     .loc    1    11    0
>  #  11  }
>     ldw $24,-24($30)                  # [0] gra_spill1
>     ldw $7,-28($30)                   # [1] gra_spill2
>     mvtc16 ra,$24                     # [2]
>
>     mv16 $sp,$30                      # [3]
>
>     mv16 $30,$7                       # [4]
>     ret16                             # [5]
>     .end    test_f
>
> Cound gatekeep help review this?
> Thanks
>
> Gang
>

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel

Reply via email to