On Fri, 28 Oct 2011, Sergey Ostanevich wrote: > On Fri, Oct 28, 2011 at 12:16 PM, Richard Guenther <rguent...@suse.de> wrote: > > On Thu, 27 Oct 2011, Uros Bizjak wrote: > > > >> Hello! > >> > >> > Here's a patch for PR47698, which is about CMOV should not be > >> > generated for memory address marked as volatile. > >> > Successfully bootstrapped and passed make check on > >> > x86_64-unknown-linux-gnu. > >> > >> > >> PR rtl-optimization/47698 > >> * config/i386/i386.c (ix86_expand_int_movcc) prevent CMOV generation > >> for volatile mem > >> > >> PR rtl-optimization/47698 > >> * gcc.target/i386/47698.c: New test > >> > >> Please use punctuation marks and correct capitalization in ChangeLog > >> entries. > >> > >> OTOH, do we want to fix this per-target, or in the middle-end? > > > > The middle-end pattern documentation does not say operands 2 and 3 > > are not evaluated if they do not end up being stored, so a middle-end > > fix is more appropriate. > > > > Richard. > > > > I have two observations: > > - 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 > > 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.
I suppose it's never safe for all architectures that support memory operands in the source operand. Richard.
