From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1637 invoked by alias); 28 Oct 2011 12:52:46 -0000 Received: (qmail 1622 invoked by uid 22791); 28 Oct 2011 12:52:45 -0000 X-SWARE-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,TW_ZJ X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 28 Oct 2011 12:52:25 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.221.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id A84A68FB75; Fri, 28 Oct 2011 14:52:24 +0200 (CEST) Date: Fri, 28 Oct 2011 13:39:00 -0000 From: Richard Guenther To: Sergey Ostanevich Cc: Uros Bizjak , gcc-patches@gcc.gnu.org, "H.J. Lu" Subject: Re: [PATCH i386] PR47698 no CMOV for volatile mem In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323584-40291136-1319806344=:26779" Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-10/txt/msg02657.txt.bz2 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323584-40291136-1319806344=:26779 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT Content-length: 1558 On Fri, 28 Oct 2011, Sergey Ostanevich wrote: > On Fri, Oct 28, 2011 at 12:16 PM, Richard Guenther 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. --8323584-40291136-1319806344=:26779--