On 11/06/2015 12:30 PM, Bernd Schmidt wrote:
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.
may_trap_or_fault_p already has this kind of knowledge. It just doesn't
know if the memory is a read or a write. Hence my suggestion we should
fix may_trap_or_fault_p.
Essentially we pass in the type of access, read, write, unknown (where
unknown must essentially be treated as write). That gets passed down
into the helpers where it's taken into account. Particularly in
rtx_addr_can_trap_p_1.
My concern with relying on MEM_READONLY_P and/or may_trap_or_fault_p is
we know that may_trap_or_fault_p been called before in cases where it's
returned false for readonly memory locations. Ripping out
noce_mem_write_may_trap_or_fault_p without fixing may_trap_or_fault_p
introduces a latent code code generation issue.
Jeff
