On Thu, Sep 01, 2005 at 08:52:29PM +0100, Joern RENNECKE wrote: > 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.
We don't consider stack overflow at all. Given that the stack is full, we can't actually do anything about it in many cases. For instance, we don't support unwinding through sigaltstack, even if the target supports it. Given libjava as the common use case, we're mostly interested in null pointer dereferences. But there is some amount of disagreement about what MEM_NOTRAP_P and TREE_THIS_NOTRAP mean. The later is documented to *not* be set for out-of-bounds array accesses, including accessing one past the end of an array in the local stack frame. Which is not consistent with the rtl-level "anything based off the frame pointer can't trap", and doesn't consider the offset at all. I'm not actually sure what the Correct stance is here. > 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. Indeed, which is why my message was addressed to all port maintainers. As a practical short-term concern, rtx_addr_can_trap_p will not return true for any stack based reference, including push/pop. So for 4.1, nothing need be done. Longer term, the answer to the "what does notrap mean" may demand that rtx_addr_can_trap_p *not* be queried, so it would be better to set the bit when possible. The hppa problem is due to manual reloading of the address into a scratch register, so the frame pointer was no longer visible, and then discarding the reload-supplied MEM that had NOTRAP set. > 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. I agree completely. This should be done before a lot of target code gets uglified. r~
