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: Michael Matz <matz at suse dot de>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, Bernd Schmidt <bschmidt at redhat dot com>, Jeff Law <law at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Sebastian Pop <sebpop at gmail dot com>
- Date: Wed, 25 Nov 2015 16:16:32 +0100 (CET)
- Subject: Re: Remove noce_mem_write_may_trap_or_fault_p in ifcvt
- Authentication-results: sourceware.org; auth=none
- References: <563D170B dot 3010800 at redhat dot com> <564CCE73 dot 1090907 at redhat dot com> <564D0E7C dot 9070703 at redhat dot com> <564F297B dot 8040603 at redhat dot com> <564F6D06 dot 1010806 at redhat dot com> <alpine dot LSU dot 2 dot 20 dot 1511231654270 dot 11029 at wotan dot suse dot de> <56559121 dot 6040208 at redhat dot com> <CAFiYyc3jK7pEeVq1rQUX4m=uErByYuhx3qRw3M8gE0HH6w7SEQ at mail dot gmail dot com> <alpine dot LSU dot 2 dot 20 dot 1511251418060 dot 11029 at wotan dot suse dot de> <CAFiYyc1zoJviSEnsq9oJNzKRntxeWEKi58QDvqsL5FdaxXFanw at mail dot gmail dot com> <20151125150014 dot GZ5675 at tucnak dot redhat dot com>
Hi,
On Wed, 25 Nov 2015, Jakub Jelinek wrote:
> > That looks bogus to me. It misses asm()s and at least today
> > nonfreeing_call_p too much checks what it sounds like it checks. In
> > practice it might work though. At least all the __sync_* and
> > __atomic_* calls are _not_ barriers this way. A pthread_mutex_lock is
> > though as we don't have a builtin for it.
> >
> > I'd change the above to a conservative
> >
> > if ((is_gimple_call (stmt) || is_gimple_asm (stmt)) && gimple_vuse (stmt))
>
> nonfreeing_call_p is one necessary condition (if that is true, it means
> the call could mean that the first access does not trap while the second one
> does).
Yes, Richis test is conservatively catching this as well (it's clear the
table for all calls and asms that even remotely can change memory state
(well, when using gimple_vdef, not gimple_vuse).
Ciao,
Michael.