From patchwork Thu Oct 29 18:43:29 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Henderson X-Patchwork-Id: 537976 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 0A1111402D6 for ; Fri, 30 Oct 2015 05:43:42 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=Xn2hlj/g; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:to :from:subject:cc:message-id:date:mime-version:content-type; q= dns; s=default; b=OTd6fOW0H1OVTMBxb7pc6HSA8McT4xWgNr7No+Fz4XK4su SXr0nPqPQ+YHDbEu4KFdNdyWOcMA5k0j09+JPNtUqrH9YB5iq+rjrS7NE9hJ4x0J bl27NyecpcFJl+BBUD/7mAG9q+T/ruoTG7w7osUxV1sbYyxFpTq9vH1WHVsRo= 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:to :from:subject:cc:message-id:date:mime-version:content-type; s= default; bh=8rAkcSmoe0vPWFy/3IbjQ9Euako=; b=Xn2hlj/gwfmYWE5+zqFH xntgmNARa+ow+XE5LYCyxhDQxJkkWYVSgkRciA47ko26fl2IdIBwXcEajxL4ra2h lwLlUeonB+4lGDgHm09pnYFxfyUuZoOn5u4ZP6LvwS2q4rNrBsQjVWOkIx0IkZPu i2gvlS5lqtVjFZuRDNweQ98= Received: (qmail 112520 invoked by alias); 29 Oct 2015 18:43:35 -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 112510 invoked by uid 89); 29 Oct 2015 18:43:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 29 Oct 2015 18:43:33 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 07A1AC0AEE44; Thu, 29 Oct 2015 18:43:31 +0000 (UTC) Received: from anchor.twiddle.net (vpn-231-99.phx2.redhat.com [10.3.231.99]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9TIhV1q004400; Thu, 29 Oct 2015 14:43:31 -0400 To: GCC Patches From: Richard Henderson Subject: Fix target/68124 X-Enigmail-Draft-Status: N1110 Cc: Uros Bizjak Message-ID: <563268D1.6030706@redhat.com> Date: Thu, 29 Oct 2015 11:43:29 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 X-IsSubscribed: yes My fix for PR 67609 caused problems for -m32 -march=corei7, a combination that I hadn't tested. My feeling is that for post-reload splitters that want to frob a register to a different mode, we ought to use something more specific than gen_lowpart. Perhaps adjust_reg_mode, or perhaps something new and more specific. But I'm not going to try to audit the whole backend at this stage. Anyway, I've tightened the test to the exact conditions that caused 67609 problems in the expander; one can hope that everything else is intentional in the backend and won't cause problems... Committed. r~ PR target/68124 PR rtl-opt/67609 * config/i386/i386.c (ix86_cannot_change_mode_class): Tighten sse check to the exact conditions of PR 67609. diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index 82fd054..8476677 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -43031,22 +43031,28 @@ ix86_cannot_change_mode_class (machine_mode from, machine_mode to, if (MAYBE_FLOAT_CLASS_P (regclass)) return true; - /* Vector registers do not support QI or HImode loads. If we don't - disallow a change to these modes, reload will assume it's ok to - drop the subreg from (subreg:SI (reg:HI 100) 0). This affects - the vec_dupv4hi pattern. - - Further, we cannot allow word_mode subregs of full vector modes. - Otherwise the middle-end will assume it's ok to store to - (subreg:DI (reg:TI 100) 0) in order to modify only the low 64 bits - of the 128-bit register. However, after reload the subreg will - be dropped leaving a plain DImode store. This is indistinguishable - from a "normal" DImode move, and so we're justified to use movsd, - which modifies the entire 128-bit register. - - Combining these two conditions, disallow all narrowing mode changes. */ if (MAYBE_SSE_CLASS_P (regclass) || MAYBE_MMX_CLASS_P (regclass)) - return GET_MODE_SIZE (to) < GET_MODE_SIZE (from); + { + int from_size = GET_MODE_SIZE (from); + int to_size = GET_MODE_SIZE (to); + + /* Vector registers do not support QI or HImode loads. If we don't + disallow a change to these modes, reload will assume it's ok to + drop the subreg from (subreg:SI (reg:HI 100) 0). This affects + the vec_dupv4hi pattern. */ + if (from_size < 4) + return true; + + /* Further, we cannot allow word_mode subregs of full vector modes. + Otherwise the middle-end will assume it's ok to store to + (subreg:DI (reg:TI 100) 0) in order to modify only the low 64 bits + of the 128-bit register. However, after reload the subreg will + be dropped leaving a plain DImode store. This is indistinguishable + from a "normal" DImode move, and so we're justified to use movsd, + which modifies the entire 128-bit register. */ + if (to_size == UNITS_PER_WORD && from_size > UNITS_PER_WORD) + return true; + } return false; }