From patchwork Sat Mar 1 00:11:07 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bill Schmidt X-Patchwork-Id: 325376 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id C856B2C00BC for ; Sat, 1 Mar 2014 11:11:25 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:subject:from:to:cc:date:content-type :content-transfer-encoding:mime-version; q=dns; s=default; b=Lgf PfZ4LAGvW85rSgK4lcMj3Am68KV9luujwp5/nt2iPZ/IBMYLjolS47zonqUSNxQC csNLlradC8dOICeuxaZBikw9kxcGUy8b4pu+8I+BBplpLlMgToyorTBw9Le6nfTq SUOJEM30EC1TJOjOjy+YDQFVL32U8nC8ZI1XyZ1U= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:subject:from:to:cc:date:content-type :content-transfer-encoding:mime-version; s=default; bh=vW3SI1iHc C6xIsgqw5FrERMw8EY=; b=tsEIcX3iIJqxvspfIchKkjybHJ6cvhrH2wLJlgX9E Qiqnpbe1MnEvbaScvuWZWPBCemWctT7T6E4tziLBxHlL5eOwNkoBMQHbIdykaQ/T TrRRM2gilcOsCihPjf93h165ei+ETtPIQLiKso6D3ZDUZaJqa/KZoskz/tqcET2p DA= Received: (qmail 24921 invoked by alias); 1 Mar 2014 00:11:17 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 24910 invoked by uid 89); 1 Mar 2014 00:11:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e28smtp08.in.ibm.com Received: from e28smtp08.in.ibm.com (HELO e28smtp08.in.ibm.com) (122.248.162.8) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Sat, 01 Mar 2014 00:11:16 +0000 Received: from /spool/local by e28smtp08.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sat, 1 Mar 2014 05:41:10 +0530 Received: from d28dlp02.in.ibm.com (9.184.220.127) by e28smtp08.in.ibm.com (192.168.1.138) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Sat, 1 Mar 2014 05:41:09 +0530 Received: from d28relay01.in.ibm.com (d28relay01.in.ibm.com [9.184.220.58]) by d28dlp02.in.ibm.com (Postfix) with ESMTP id 13849394003E for ; Sat, 1 Mar 2014 05:41:09 +0530 (IST) Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63]) by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s210An8741877556 for ; Sat, 1 Mar 2014 05:40:49 +0530 Received: from d28av01.in.ibm.com (localhost [127.0.0.1]) by d28av01.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s210B8hY004803 for ; Sat, 1 Mar 2014 05:41:08 +0530 Received: from [9.50.21.169] (dyn9050021169.mts.ibm.com [9.50.21.169] (may be forged)) by d28av01.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s210B5OJ004767; Sat, 1 Mar 2014 05:41:06 +0530 Message-ID: <1393632667.3554.84.camel@gnopaine> Subject: [PATCH, rs6000] Restrict reload use of FLOAT_REGS From: Bill Schmidt To: gcc-patches@gcc.gnu.org Cc: dje.gcc@gmail.com, uweigand@de.ibm.com Date: Fri, 28 Feb 2014 18:11:07 -0600 Mime-Version: 1.0 X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14030100-2000-0000-0000-00000FF3ABF4 X-IsSubscribed: yes Hi, We've encountered a rare bug that occurs when attempting to reload for an unaligned store in DImode. For an unaligned store, using stfd gets preference over std since stfd doesn't have an alignment restriction and therefore the "m" constraint matches. However, when there is not a register available for the REG to be stored, register elimination can replace the REG with its REQ_EQUIV. When this is a PLUS, we end up with an attempt to compute an integer add into a floating-point register, and things rapidly go downhill. We had some internal discussion and determined the best way to fix this is to avoid ever using FLOAT_REGS for a PLUS in rs6000_preferred_reload_class, similar to what's currently done to avoid loading constants into FLOAT_REGS. Uli Weigand pointed out that this existing test is actually a bit too strong, as rclass could be ALL_REGS and this prevents us from using GENERAL_REGS in that case. So I've relaxed that test to only look for superclasses of FLOAT_REGS. (If you feel this is too risky, I can avoid that change.) The patch below fixes the one case where we've observed this bug in the wild (it occurred for a particular snapshot of code for an internal build that doesn't match any public branch). Because it's dependent on register spill, it is very difficult to try to produce a test case that isn't too fragile, so I haven't tried to add one. Bootstrapped and tested on powerpc64le-unknown-linux-gnu (--with-cpu=power8) and powerpc64-unknown-linux-gnu (--with-cpu=power7) with no regressions. Is this ok for trunk? Thanks, Bill 2014-02-28 Bill Schmidt * config/rs6000/rs6000.c (rs6000_preferred_reload_class): Disallow PLUS rtx's from reloading into a superset of FLOAT_REGS; relax constraint on constants to only prevent them from being reloaded into a superset of FLOAT_REGS. Index: gcc/config/rs6000/rs6000.c =================================================================== --- gcc/config/rs6000/rs6000.c (revision 208207) +++ gcc/config/rs6000/rs6000.c (working copy) @@ -16751,7 +16751,8 @@ rs6000_preferred_reload_class (rtx x, enum reg_cla && easy_vector_constant (x, mode)) return ALTIVEC_REGS; - if (CONSTANT_P (x) && reg_classes_intersect_p (rclass, FLOAT_REGS)) + if ((CONSTANT_P (x) || GET_CODE (x) == PLUS) + && reg_class_subset_p (FLOAT_REGS, rclass)) return NO_REGS; if (GET_MODE_CLASS (mode) == MODE_INT && rclass == NON_SPECIAL_REGS)