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