This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [MIPS] Implement static stack checking
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 22 Oct 2012 23:47:46 +0200
- Subject: Re: [MIPS] Implement static stack checking
- References: <17103666.Uvnd1BXjPp@polaris> <87bofuntaw.fsf@talisman.home>
> This function doesn't work with MIPS16 mode. Maybe just:
>
> if (TARGET_MIPS16)
> sorry ("MIPS16 stack probes");
>
> (We can't test TARGET_MIPS16 in something like STACK_CHECK_STATIC_BUILTIN
> because MIPS16ness is a per-function property.)
I put
if (TARGET_MIPS16)
sorry ("-fstack-check=specific not implemented for MIPS16");
> Please use MIPS_PROLOGUE_TEMP for r3 (and probably rename r3).
> I suppose GP_REG_FIRST + 12 should be MIPS_PROLOGUE_TEMP2, probably as:
>
> #define MIPS_PROLOGUE_TEMP2_REGNUM \
> (TARGET_MIPS16 ? gcc_unreachable () \
> cfun->machine->interrupt_handler_p ? K1_REG_NUM : GP_REG_FIRST + 12)
>
> #define MIPS_PROLOGUE_TEMP2(MODE) \
> gen_rtx_REG (MODE, MIPS_PROLOGUE_TEMP2_REGNUM)
>
> and update the block comment above the MIPS_PROLOGUE_TEMP_REGNUM definition.
Done.
> I Might Be Wrong, but it looks like this won't probe at FIRST + SIZE
> in the case where SIZE == ROUNDED_SIZE, because the loop exits on that
> value without probing it. Should the last line be unconditional,
> or does the loop need to be a do-while instead? (I suppose the latter,
> so that there isn't a hole bigger than PROBE_INTERVAL in the
> SIZE != ROUNDED_SIZE case?)
The loop probes at FIRST + N * PROBE_INTERVAL for values of N from 1 until it
is equal to ROUNDED_SIZE, inclusive, so FIRST + SIZE is always probed.
> This only works in noreorder mode. If there's an asm in the function,
> or something else that forces reorder mode (e.g. a -mfix-* option),
> the addition won't be put in the delay slot.
>
> "%(%<beq\t%0,%1," and "daddiu\t%0,%0,%1%>%)" should work. (Note that
> our MIPS asm output doesn't have a space before the delay slot; there's
> a blank line after it instead. That's all handled by output_asm_insn
> though.)
Thanks for the incantation!
> OK with those changes, thanks.
I'll retest with the changes tomorrow. Thanks for the review.
--
Eric Botcazou