This is the mail archive of the gcc-patches@gcc.gnu.org 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: [PATCH] aarch64: Add split-stack initial support


Adhemerval Zanella writes:

> On 08/08/2016 07:58, Jiong Wang wrote:
>> 
>> Adhemerval Zanella writes:
>> 
>
> Below it the last iteration patch, however I now seeing some similar issue
> s390 hit when building libgo:
>
> ../../../gcc-git/libgo/go/syscall/socket_linux.go:90:1: error: flow control insn inside a basic block
> (jump_insn 90 89 91 14 (set (pc)
>         (if_then_else (geu (reg:CC 66 cc)
>                 (const_int 0 [0]))
>             (label_ref 92)
>             (pc))) ../../../gcc-git/libgo/go/syscall/socket_linux.go:90 -1
>      (nil)
>  -> 92)
> ../../../gcc-git/libgo/go/syscall/socket_linux.go:90:1: internal compiler error: in rtl_verify_bb_insns, at cfgrtl.c:2658
> 0xac35af _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
>
> It shows only with -O2, which I think it due how the block is reorganized
> internally and regarding the pseudo-return instruction inserted by split-stack.
> I am still debugging the issue and how to proper fix it, so if you have any
> advice I open to suggestions.
> ...
> ...
> +void
> +aarch64_split_stack_space_check (rtx size, rtx label)
> +{
> +  rtx mem, ssvalue, compare, jump, temp;
> +  rtx requested = gen_reg_rtx (Pmode);
> +  /* Offset from thread pointer to __private_ss.  */
> +  int psso = 0x10;
> +
> +  /* Load __private_ss from TCB.  */
> +  ssvalue = gen_rtx_REG (Pmode, R9_REGNUM);
> +  emit_insn (gen_aarch64_load_tp_hard (ssvalue));
> +  mem = gen_rtx_MEM (Pmode, plus_constant (Pmode, ssvalue, psso));
> +  emit_move_insn (ssvalue, mem);
> +
> +  /* And compare it with frame pointer plus required stack.  */
> +  if (CONST_INT_P (size))
> +     emit_insn (gen_add3_insn (requested, stack_pointer_rtx,
> +			       GEN_INT (-INTVAL (size))));

If the constant size doesn't fit into an add instruction, this statement
will generates NULL, then the following comparision is wrong I guess.

I am not sure if this is reason for the ICE you mentioned above.

Meanwhile for the nop scheduling issue, I do see the following
instruction sequences generated.  "add" is scheduled before nop.

        mov     x10, -4160
        add     x10, sp, x10
        nop

I currently don't have good idea on tie the "nop" with "mov", for TLS
relaxation which require similar instruction tie, we are simply use
single RTL pattern to output multiply instructions at final assembly
output stage.

> +  else
> +    {
> +      size = force_reg (Pmode, size);
> +      emit_move_insn (requested, gen_rtx_MINUS (Pmode, stack_pointer_rtx,
> +						size));
> +    }
> +
> +  /* Jump to __morestack call if current __private_ss is not suffice.  */
> +  compare = aarch64_gen_compare_reg (LT, requested, ssvalue);
> +  temp = gen_rtx_IF_THEN_ELSE (VOIDmode,
> +			       gen_rtx_GEU (VOIDmode, compare, const0_rtx),
> +			       gen_rtx_LABEL_REF (VOIDmode, label),
> +			       pc_rtx);

-- 
Regards,
Jiong


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