From patchwork Tue Sep 23 01:26:42 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Makarov X-Patchwork-Id: 392194 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 D5AB81400B7 for ; Tue, 23 Sep 2014 11:27:01 +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 :message-id:date:from:mime-version:to:cc:subject:content-type; q=dns; s=default; b=Mm90qB04a0Sb+m7CO7vn06BzpVv06dE1Os6ugFizc8u h5GU6bKAtdt3a65cgZMupJKHgLnmtzhYsEFNWCECSID2tCbSWbTwfw1KmFB7cp3J b2NiPuscqKNYjlUAfm3NrT1S3A5zOsjQimY7EAI7zMppCUI7YSW3sGpuYCTDl0HQ = 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:date:from:mime-version:to:cc:subject:content-type; s=default; bh=oI32s89KrzX+BgW2P/XiDu9IN60=; b=QpTZ++P4NlH57aljQ pm1mnlUHDp3fBXoSxqeZ4gCuPv7tiyB+rYHN3Z1EizOLvPvDbbAZ8Pz8aw/1IB1F 8WHlMMiBqBIHXs4TB58DcFEzjM796UFLkZkyrHbiny5MmYL6Rz2z3ih34vva3kGa BvW1ZwtbeP/+H41e2AWVyWBeJA= Received: (qmail 19474 invoked by alias); 23 Sep 2014 01:26:54 -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 19443 invoked by uid 89); 23 Sep 2014 01:26:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.3 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_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; Tue, 23 Sep 2014 01:26:48 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8N1Qk7O014700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 22 Sep 2014 21:26:46 -0400 Received: from VMBP.local (vpn-52-153.rdu2.redhat.com [10.10.52.153]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8N1Qh6E013282; Mon, 22 Sep 2014 21:26:44 -0400 Message-ID: <5420CC52.8030707@redhat.com> Date: Mon, 22 Sep 2014 21:26:42 -0400 From: Vladimir Makarov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: GCC Patches , Uros Bizjak CC: Richard Sandiford Subject: RFA: another patch to fix PR61360 X-IsSubscribed: yes The previous patch to solve PR61360 fixed the problem in IRA (it was easier for me to do as I know the code well) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61360 Although imo it was an ok fix, Richard expressed concerns with the patch and the practice to have different enable attribute values depending on the current pass. I don't understand why "x,m" alternative is better to "x,r" and "x,r" should be disabled. Even if the path from general regs to sse regs is slow (usually such slow path is implemented internally by micro-architecture through cache). "x,r" alternative results in only smaller insns (including number of insns) with probably the same time for the movement. So "x,r" should be at least no slower, insn cache should have more locality, and less overhead for decoding/translating insns. Here I propose another solution avoiding to have different enable attribute values. The patch was successfully bootstrapped on x86/x86-64 and tested with and without -march=amdfam10 (actually the patch results in 2 less failures when -march=amdfam10 were used). Uros, is i386.md change ok for the trunk? 2014-09-22 Vladimir Makarov PR target/61360 * lra.c (lra): Remove call of recog_init. * config/i386/i386.md (*float2_sse): Always enable first alternative. Index: config/i386/i386.md =================================================================== --- config/i386/i386.md (revision 215337) +++ config/i386/i386.md (working copy) @@ -4795,14 +4795,6 @@ (symbol_ref "TARGET_MIX_SSE_I387 && X87_ENABLE_FLOAT (mode, mode)") - (eq_attr "alternative" "1") - /* ??? For sched1 we need constrain_operands to be able to - select an alternative. Leave this enabled before RA. */ - (symbol_ref "TARGET_INTER_UNIT_CONVERSIONS - || optimize_function_for_size_p (cfun) - || !(reload_completed - || reload_in_progress - || lra_in_progress)") ] (symbol_ref "true"))) ]) Index: lra.c =================================================================== --- lra.c (revision 215358) +++ lra.c (working copy) @@ -2135,11 +2135,6 @@ lra (FILE *f) lra_in_progress = 1; - /* The enable attributes can change their values as LRA starts - although it is a bad practice. To prevent reuse of the outdated - values, clear them. */ - recog_init (); - lra_live_range_iter = lra_coalesce_iter = 0; lra_constraint_iter = lra_constraint_iter_after_spill = 0; lra_inheritance_iter = lra_undo_inheritance_iter = 0;