This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Remove noce_mem_write_may_trap_or_fault_p in ifcvt
- From: Bernd Schmidt <bschmidt at redhat dot com>
- To: Jeff Law <law at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>, Sebastian Pop <sebpop at gmail dot com>
- Date: Fri, 6 Nov 2015 20:30:08 +0100
- Subject: Re: Remove noce_mem_write_may_trap_or_fault_p in ifcvt
- Authentication-results: sourceware.org; auth=none
- References: <563CE17F dot 6090308 at t-online dot de> <563CF3F0 dot 8010703 at redhat dot com> <563CF504 dot 2070604 at redhat dot com> <563CFD92 dot 7020808 at redhat dot com>
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