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.
