Re: Remove noce_mem_write_may_trap_or_fault_p in ifcvt

[Jeff Law <law@redhat.com>]

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