From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116514 invoked by alias); 12 Mar 2015 15:37:28 -0000 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 Received: (qmail 116504 invoked by uid 89); 12 Mar 2015 15:37:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_FROM_URIBL_PCCC,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-ie0-f174.google.com Received: from mail-ie0-f174.google.com (HELO mail-ie0-f174.google.com) (209.85.223.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 12 Mar 2015 15:37:27 +0000 Received: by ieclw3 with SMTP id lw3so45687104iec.2 for ; Thu, 12 Mar 2015 08:37:24 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.25.231 with SMTP id f7mr102576095igg.48.1426174634757; Thu, 12 Mar 2015 08:37:14 -0700 (PDT) Received: by 10.36.107.85 with HTTP; Thu, 12 Mar 2015 08:37:14 -0700 (PDT) In-Reply-To: <20150312152952.GA11678@ibm-tiger.the-meissners.org> References: <20150305200638.GA3059@ibm-tiger.the-meissners.org> <20150311222120.GA16631@ibm-tiger.the-meissners.org> <20150312152952.GA11678@ibm-tiger.the-meissners.org> Date: Thu, 12 Mar 2015 15:37:00 -0000 Message-ID: Subject: Re: [PATCH] PR target/65240, Fix Power{7,8} insn constraint issue with -O3 -ffast-math From: David Edelsohn To: Michael Meissner , GCC Patches Content-Type: text/plain; charset=ISO-8859-1 X-SW-Source: 2015-03/txt/msg00692.txt.bz2 On Thu, Mar 12, 2015 at 11:29 AM, Michael Meissner wrote: > On Wed, Mar 11, 2015 at 08:52:54PM -0400, David Edelsohn wrote: >> On Wed, Mar 11, 2015 at 6:21 PM, Michael Meissner >> wrote: >> > On Wed, Mar 11, 2015 at 01:02:06PM -0400, David Edelsohn wrote: >> >> I am concerned with the create_TOC_reference use for TARGET_TOC. Has >> >> this been tested with big endian -mcmodel=small? >> > >> > Yes, that was a problem. Patch coming up soon. Thanks. >> >> Can you call rs6000_emit_move_directly? > > Well, I can, but I would have to have some sort of flag that says after the > split1 pass not to allow FP constants in move (other than 0.0). It is doable, > but it does touch more areas in the rs6000 back end. > > I am starting to think that it is just simpler to rip out all of the special > fast math handling of constants, considering the multiply by reciprocal support > has moved to SSA/tree and away from RTL. Did you want me to investigate the > performance implications of removing it now (rather than waiting to GCC 6.0), > or just do the more limited patch that I've been pursuing. Please check on the performance implications of removing the special constant support. I know that it is late, but I think that ripping it out is less risky than trying to fix this, if the performance impact is not bad. Thanks, David