MEM_NONTRAP_P and push/pop alias set (Was: Re: [attn port maintainers] fix 23671)

[Joern RENNECKE]

> My current thinking is that, with a few exceptions like prologue
> and epilogue generation, it should be considered a BUG if a port
> uses gen_rtx_MEM.  Almost always one should be using something
> from the adjust_address family of routines.

What are the exact semantics of MEM_NOTRAP_P ?  The documentation
does not agree with the source.  reload sets MEM_NOTRAP_P on
registers that are spilled to memory.  However, writing to these
MEMs can trap if we have a stack overflow.

Ports also have to write to stack memory - in the prologue, and
for copies that use secondary memory (the SH doesn't allocate seondary
memory through the reload mechanisms, but it uses push / pop for 64 bit
copies between general purpose and floating point registers).  Thus,
this question is probably relevant for every port maintainer.

Moreover, register pushes/pops (other than for the return address in the
presence of builtin_return_address) in the prologue / epilogue can't alias
other memory accesses, and on ACCUMULATE_OUTGOING_ARGS, neither can
temporary pushes/pops (unless shrinkwrapping gets implemented).

Therefore, I think it would make sense to have a utility function that
generates a MEM with MEM_NONTRAP_P set to the appropriate value, and
a specific alias set.  We already have gen_const_mem for readonly
memory, so maybe that could be gen_pushpop_mem.