Re: Remove noce_mem_write_may_trap_or_fault_p in ifcvt

[Jeff Law <law at redhat dot com>]

On 11/06/2015 11:44 AM, Bernd Schmidt wrote:
> On 11/06/2015 07:39 PM, Jeff Law wrote:
> > Given the name "..may_trap_or_fault_p" ISTM that its mode of operation
> > should be to return true (the safe value) unless we can prove the write
> > will not fault.  The more cases we can prove true, the better AFAICT.
> >
> > The PLUS case looks totally wrong.  Though it could possibly be made
> > correct by looking for [sp,fp,ap] + offset addresses and verifying we're
> > doing a mis-aligned write.  We'd probably also need some kind of
> > sensible verification that the offset isn't too large/small.
>
> I'm guessing this is already covered by the call to may_trap_or_fault_p.
Yea, it looks like may_trap_or_fault_p tries to handle unaligned and 
wacky offsets for sp,fp,ap relative addresses.

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).


> The only additional thing that this function tries to prove is that the
> mem isn't readonly. IMO either MEM_READONLY_P is sufficient for that
> (and my patches operate under that assumption), or it isn't sufficient
> and no amount of checking the address is going to make the function useful.
Right.  I think we've come to agreement on what 
noce_mem_write_may_trap_or_fault_p is trying to to.

The problem I have is I don't think we can assume that the lack of 
MEM_READONLY_P is sufficient to determine that a particular memory 
reference is not to readonly memory.   ie, when MEM_READONLY_P is set, 
the object must be readonly, when it is not set, we know nothing.


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.

Jeff