On 11/06/2015 08:20 PM, Jeff Law wrote:
So maybe what noce_mem_write_may_trap_or_fault_p is really trying to do is take objects where may_trap_or_fault_p returns false, but which in fact may fault if we write that memory? ie, working around lameness in may_trap_or_fault_p not knowing the context (ie read vs write).
Yes exactly, that is the aim - detect extra possibilities for faults knowing that the context is a write.
I think what we really want here is to fix may_trap_or_fault_p to be safe. It's returning "false" in cases where it really ought be returning "true". Then we just use may_trap_or_fault_p, dropping noce_mem_write_may_trap_or_fault_p.
Well, I think if MEM_READONLY_P is insufficient (and I guess people could cast away const - bother), then the current noce_mem_write_may_trap_or_fault_p should be simplified to "return true;" and eliminated. We could try to special case stack accesses within a known limit later on.
Maybe it doesn't even matter given that we call noce_can_store_speculate immediately after this test.
Bernd
