This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: [PATCH i386] PR47698 no CMOV for volatile mem

From: Richard Henderson <rth at redhat dot com>
To: Sergey Ostanevich <sergos dot gnu at gmail dot com>
Cc: Richard Guenther <rguenther at suse dot de>, Uros Bizjak <ubizjak at gmail dot com>, gcc-patches at gcc dot gnu dot org, "H.J. Lu" <hjl dot tools at gmail dot com>
Date: Fri, 28 Oct 2011 08:51:08 -0700
Subject: Re: [PATCH i386] PR47698 no CMOV for volatile mem
References: <CAFULd4aMR_Lf4rVbagtyKTEove4yoKinSWiXwtKNTo5ph8yjNw@mail.gmail.com> <alpine.LNX.2.00.1110281013340.26779@zhemvz.fhfr.qr> <CAGYS_TKCCRgaG8U6-=77imhBG7JmNtUN=bYoZX7b1ajYDQPZhQ@mail.gmail.com>

On 10/28/2011 05:49 AM, Sergey Ostanevich wrote:
> - the code for CMOV is under #ifdef in the mddle-end, which is
> explicitly marked as "have to be removed" (ifcvt.c:1446)
> - I have no clear evidence all platforms that support conditional move
> have the same semantics that lead to the PR

We're on solid ground here.  The arguments are assumed to always be
evaluated in RTL, *except* in the case of COND_EXEC.  Only true
predication can avoid an exception or side effects of touching memory.

> I think the best way to address both concerns is to implement code
> that relies on Ð new hookup "volatile-safe CMOV" that is false by
> default.

We do not need a new hook.

r~

References:
- Re: [PATCH i386] PR47698 no CMOV for volatile mem
  - From: Uros Bizjak
- Re: [PATCH i386] PR47698 no CMOV for volatile mem
  - From: Richard Guenther
- Re: [PATCH i386] PR47698 no CMOV for volatile mem
  - From: Sergey Ostanevich

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]