From patchwork Sun Oct 28 09:13:51 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Uros Bizjak X-Patchwork-Id: 194666 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]) by ozlabs.org (Postfix) with SMTP id 44DD42C0084 for ; Sun, 28 Oct 2012 20:14:01 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1352020442; h=Comment: DomainKey-Signature:Received:Received:Received:Received: MIME-Version:Received:Received:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:Mailing-List: Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:Sender:Delivered-To; bh=sLDYQO4ZHm4c27a/SJaN44WEg/w=; b=DbmSQzhYPYmQjvB4kdoVoss1vNEU0bH9NuasJNpO7N+sKN/Djm/NjEk6Ll3SrC xzC0ZnM6UqdMxqBdvQb9b012JxAAQzLMctl+gSclFfg6g1/XraSTivqdUIpbzTWP LDIJs9gjsb3exnSfW+4rlrPMSPWDABNFUo5kCHzvE67QA= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:MIME-Version:Received:Received:In-Reply-To:References:Date:Message-ID:Subject:From:To:Cc:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=MxrVy1s6oq3J9YOOw3LSDIJbN+5EBPLWBlhYr4aDXRM4qK7zchv32EFQHX568K XYIR3I/or1TFxtOnc7HPagiqA1AT8XSzQ22p4KQvhjDUuuUJnni0W0OVV4yv1Waa cRlDnFiDOXzsATrw25vz3AF5Y3PYQIeW5dl+sndA1rLlo=; Received: (qmail 13547 invoked by alias); 28 Oct 2012 09:13:58 -0000 Received: (qmail 13538 invoked by uid 22791); 28 Oct 2012 09:13:57 -0000 X-SWARE-Spam-Status: No, hits=-5.0 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, KHOP_RCVD_TRUST, KHOP_THREADED, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE, TW_ZJ X-Spam-Check-By: sourceware.org Received: from mail-pa0-f47.google.com (HELO mail-pa0-f47.google.com) (209.85.220.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 28 Oct 2012 09:13:52 +0000 Received: by mail-pa0-f47.google.com with SMTP id fa11so2623997pad.20 for ; Sun, 28 Oct 2012 02:13:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.90.33 with SMTP id bt1mr74414130pab.49.1351415631662; Sun, 28 Oct 2012 02:13:51 -0700 (PDT) Received: by 10.66.246.232 with HTTP; Sun, 28 Oct 2012 02:13:51 -0700 (PDT) In-Reply-To: References: Date: Sun, 28 Oct 2012 10:13:51 +0100 Message-ID: Subject: Re: [RFC PATCH, i386]: Remove peephole2s for (subreg (operator (...)(...))) RTXes From: Uros Bizjak To: "H.J. Lu" Cc: gcc-patches@gcc.gnu.org, Richard Sandiford 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 On Sun, Oct 28, 2012 at 9:57 AM, Uros Bizjak wrote: > On Sun, Oct 28, 2012 at 2:37 AM, H.J. Lu wrote: > >>>> As suggested by Richard S. [1], after the patch that converts subreg:M >>>> (op:N (...)(...)) to op:M (subreg:M (...) subreg:M (...)), we can >>>> remove several peephole2 patterns that handle subregs of PLUS, MINUS >>>> and MULT operators. I have attached RFC prototype patch that will >>>> trigger an ICE when to-be-removed pattern triggers, with the intention >>>> that these patterns wil be removed entirely (An "invalid" pattern was >>>> indeed generated elsewhere, see patch). >>>> >>>> 2012-10-18 Uros Bizjak >>>> >>>> * config/i386/i386.md (ashift to lea splitter): Split to SImode mult. >>>> (simple lea to add/shift peephole2s): Remove peephole2s that operate >>>> on subregs of DImode operations. >>>> (*mov_insv_1_rex64): Use gen_int_mode to truncate >>>> const_int RTX to QImode value. >>>> (*movsi_insv_1): Ditto. >>>> >>>> The patch was bootstrapped and regression tested on >>>> x86_64-pc-linux-gnu {,-m32} without problems, but I will ask H.J. to >>>> test the patch on x32 before it is committed to mainline SVN. >>>> >>>> [1] http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01856.html >>>> >>>> Uros. >>> >>> I tested it on x32, ia32 and x86-64 with GCC testsuite and glibc. >>> There are no GCC regressions on x32. However, for glibc trunk, >>> on x32 and x86-64, I got >>> >>> make[4]: *** [/export/build/gnu/glibc-test/build-x86_64-linux/math/test-ildoubl.out] >>> Error 1 >>> make[4]: *** [/export/build/gnu/glibc-test/build-x86_64-linux/math/test-ldouble.out] >>> Error 1 >>> >>> On ia32, I got >>> >>> make[4]: *** [/export/build/gnu/glibc-32bit-test/build-i686-linux/math/test-fenv.out] >>> Error 1 >>> make[4]: *** [/export/build/gnu/glibc-32bit-test/build-i686-linux/math/test-ifloat.out] >>> Error 1 >>> make[4]: *** [/export/build/gnu/glibc-32bit-test/build-i686-linux/math/test-idouble.out] >>> Error 1 >>> make[4]: *** [/export/build/gnu/glibc-32bit-test/build-i686-linux/math/test-float.out] >>> Error 1 >>> make[4]: *** [/export/build/gnu/glibc-32bit-test/build-i686-linux/math/test-double.out] >>> Error 1 >>> >>> I am testing if they are caused by the change. >>> >> >> They are caused by this patch. I configure glibc with CFLAGS="-O3 -g" > > Can you please send me offline preprocessed sources to investigate > this failure? There is another place in the code that generates subreg > "by hand". Maybe following patch helps: --cut here-- --cut here-- Uros. Index: i386.c =================================================================== --- i386.c (revision 192872) +++ i386.c (working copy) @@ -11821,7 +11821,7 @@ ix86_decompose_address (rtx addr, struct ix86_addr return 0; } else if (GET_MODE (addr) == DImode) - addr = gen_rtx_SUBREG (SImode, addr, 0); + addr = simplify_gen_subreg (SImode, addr, DImode, 0); else if (GET_MODE (addr) != VOIDmode) return 0; }