From patchwork Sat Aug 24 10:43:46 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steven Bosscher X-Patchwork-Id: 269630 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 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "localhost", Issuer "www.qmailtoaster.com" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 00D0E2C0097 for ; Sat, 24 Aug 2013 20:44:37 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; q=dns; s=default; b=x0oeyrTl2dbH9bm 5XaAn6g2eJ9wvd0zQFTYnpJUpry3z6xwaABXGFW+1dz7MsN/kgIsFrGhwleR3dBU UXashO6GeCLQdT6QGQBmKXzZrU9sc1q7tK0RCZfbOSu5k+p23MT9mzFLCRHiNWzW tCJkweF9sddtz+apm3zvnAT19f0Q= 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 :mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; s=default; bh=SIY3hs+WYQs1l9jxRD6YF f/Egv4=; b=Z2RAkExbfdjanfu5atS54fbWrRvln1ltXhZMuyZjnHvzhzd1qqcZ5 NMqR27V9vINWp7DbugG5FOGyZYZ98GkpgxIFfkslISgRxKlaImhtoxTxG4xZMxaZ oHRw8Ak2kpETleiEWXJEmwfEJeVF1ObSoin5J5tx3DcSy3weroG94Y= Received: (qmail 3016 invoked by alias); 24 Aug 2013 10:44:29 -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 3006 invoked by uid 89); 24 Aug 2013 10:44:29 -0000 X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, KHOP_THREADED, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE, SPF_PASS autolearn=ham version=3.3.2 Received: from mail-ob0-f170.google.com (HELO mail-ob0-f170.google.com) (209.85.214.170) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Sat, 24 Aug 2013 10:44:28 +0000 Received: by mail-ob0-f170.google.com with SMTP id eh20so1652018obb.15 for ; Sat, 24 Aug 2013 03:44:27 -0700 (PDT) X-Received: by 10.182.18.9 with SMTP id s9mr4103858obd.15.1377341066935; Sat, 24 Aug 2013 03:44:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.95.73 with HTTP; Sat, 24 Aug 2013 03:43:46 -0700 (PDT) In-Reply-To: References: From: Steven Bosscher Date: Sat, 24 Aug 2013 12:43:46 +0200 Message-ID: Subject: Re: [PATCH]: Fix PR middle-end/56382 -- Only move MODE_COMPLEX_FLOAT by parts if we can create pseudos To: John David Anglin Cc: GCC Patches On Fri, Aug 23, 2013 at 2:47 AM, John David Anglin wrote: > Ping. > > > On 28-Jul-13, at 12:17 PM, John David Anglin wrote: > >> This patch fixes PR middle-end/56382 on hppa64-hp-hpux11.11. The patch >> prevents moving a complex float by parts if we can't >> create pseudos. On a big endian 64-bit target, we need a psuedo to move a >> complex float and this fails during reload. >> >> OK for trunk? >> I'm trying to understand how the patch would help... The code you're patching is: /* Move floating point as parts. */ if (GET_MODE_CLASS (mode) == MODE_COMPLEX_FLOAT + && can_create_pseudo_p () && optab_handler (mov_optab, GET_MODE_INNER (mode)) != CODE_FOR_nothing) try_int = false; /* Not possible if the values are inherently not adjacent. */ else if (GET_CODE (x) == CONCAT || GET_CODE (y) == CONCAT) try_int = false; /* Is possible if both are registers (or subregs of registers). */ else if (register_operand (x, mode) && register_operand (y, mode)) try_int = true; /* If one of the operands is a memory, and alignment constraints are friendly enough, we may be able to do combined memory operations. We do not attempt this if Y is a constant because that combination is usually better with the by-parts thing below. */ else if ((MEM_P (x) ? !CONSTANT_P (y) : MEM_P (y)) && (!STRICT_ALIGNMENT || get_mode_alignment (mode) == BIGGEST_ALIGNMENT)) try_int = true; else try_int = false; With the new test for can_create_pseudo_p, you're trying to make "try_int" be false. Apparently your failure happens if one of the operands is a MEM? Otherwise the second "else if " test would find x and y be registers and "try_int" still ends up being true. It seems to me that can_create_pseudo_p is not the right test anyway. There many be other targets that can take this path just fine without needing new registers. In the PR audit trail you say: "The problem is SCmode is the same size as DImode on this target, so the subreg can't be extracted by a move." Using can_create_pseudo_p is too big a hammer to solve this problem. The right test would be to see if you end up needing extra registers to perform the move. But emit_move_change_mode already handles that, AFAICT, so can you please try and test if the following patch solves the PR for you? Ciao! Steven Index: expr.c =================================================================== --- expr.c (revision 201887) +++ expr.c (working copy) @@ -3268,7 +3268,7 @@ emit_move_complex (enum machine_mode mode, rtx x, return get_last_insn (); } - ret = emit_move_via_integer (mode, x, y, true); + ret = emit_move_via_integer (mode, x, y, can_create_pseudo_p ()); if (ret) return ret; }