[PATCH] V5, #5 of 15: Support -fstack-protect and large stack frames

[Segher Boessenkool]

On Wed, Oct 09, 2019 at 04:22:06PM -0400, Michael Meissner wrote:
> This patch allows -fstack-protect to work with large stack frames.

I don't understand; please explain.

What I see is a workaround for not properly handling prefixed addresses
in the stack protect code (by forcing the addresses to not be prefixed at
expand time).

> +rtx
> +make_memory_non_prefixed (rtx mem)
> +{
> +  gcc_assert (MEM_P (mem));
> +
> +  rtx old_addr = XEXP (mem, 0);
> +  if (address_is_prefixed (old_addr, GET_MODE (mem), NON_PREFIXED_DEFAULT))
> +    {
> +      rtx new_addr;
> +
> +      if (GET_CODE (old_addr) == PLUS
> +	  && (REG_P (XEXP (old_addr, 0)) || SUBREG_P (XEXP (old_addr, 0)))

How can you ever have a subreg in an address?  One in Pmode even?

> +	  && CONST_INT_P (XEXP (old_addr, 1)))
> +	{
> +	  rtx tmp_reg = force_reg (Pmode, XEXP (old_addr, 1));
> +	  new_addr = gen_rtx_PLUS (Pmode, XEXP (old_addr, 0), tmp_reg);
> +	}
> +      else
> +	new_addr = force_reg (Pmode, old_addr);
> +
> +      mem = change_address (mem, VOIDmode, new_addr);

replace_equiv_address ?

> +(define_expand "stack_protect_setdi"
> +  [(parallel [(set (match_operand:DI 0 "memory_operand")
> +		   (unspec:DI [(match_operand:DI 1 "memory_operand")]
> +		   UNSPEC_SP_SET))
> +	      (set (match_scratch:DI 2)
> +		   (const_int 0))])]
> +  "TARGET_64BIT"
> +{
> +  if (TARGET_PREFIXED_ADDR)
> +    {
> +      operands[0] = make_memory_non_prefixed (operands[0]);
> +      operands[1] = make_memory_non_prefixed (operands[1]);
> +    }
> +})

It shouldn't be terribly hard to make the define_insns just *work* with
prefixed insns, instead?  Is there any reason we are sure these memory
references will not turn into something that needs prefixed insns, after
expand?  It seems fragile like this.

> +@item em
> +A memory operand that does not contain a prefixed address.

"A memory operand that does not require a prefixed instruction"?


Segher