From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105511 invoked by alias); 12 Jul 2016 15:17:14 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 105431 invoked by uid 89); 12 Jul 2016 15:17:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= 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, 12 Jul 2016 15:17:08 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6D73DC049D5A; Tue, 12 Jul 2016 15:17:07 +0000 (UTC) Received: from localhost.localdomain (vpn1-6-218.ams2.redhat.com [10.36.6.218]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6CFH57m023895; Tue, 12 Jul 2016 11:17:05 -0400 Subject: Re: [PATCH], PowerPC support to enable -mlra and/or -mfloat128 To: Segher Boessenkool References: <20160711200701.GA21095@ibm-tiger.the-meissners.org> <20160712121559.GC13551@gate.crashing.org> <7f93c3f9-6e15-257e-f573-43f2c14127fe@redhat.com> <20160712124544.GD13551@gate.crashing.org> <9614013f-5daf-a271-f476-b4bd1adab9fd@redhat.com> Cc: Richard Biener , Michael Meissner , GCC Patches , David Edelsohn , Bill Schmidt From: Bernd Schmidt Message-ID: <0c9127b4-5320-a5be-b9fd-2c50451b34c3@redhat.com> Date: Tue, 12 Jul 2016 15:17:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <9614013f-5daf-a271-f476-b4bd1adab9fd@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-07/txt/msg00662.txt.bz2 On 07/12/2016 02:48 PM, Bernd Schmidt wrote: > No. You can reproduce issues with Blackfin easily by enabling LRA for > it, and I described the C6X issues when the LRA patches were posted for > review. That was here: https://gcc.gnu.org/ml/gcc-patches/2012-10/msg00235.html The Blackfin thing happens frequently with -fomit-frame-pointer when we have (insn 66 64 70 8 (set (reg:SI 96 [ ivtmp.32 ]) (reg/f:SI 15 FP)) 19 {*movsi_insn} Which LRA transforms to an invalid insn: (insn 66 64 70 8 (set (reg:SI 15 FP [orig:96 ivtmp.32 ] [96]) (plus:SI (reg/f:SI 14 SP) (const_int 4 [0x4]))) 50 {addsi3} (expr_list:REG_EQUAL (reg/f:SI 15 FP) (nil))) Haven't fully debugged it but it looks like an instance of the same problem: not using the correct register numbers in elimination. An FP+FP addition would be fine (which is how I'm guessing we arrived at this pattern), but once you substitute the real register number you get an invalid insn. So LRA is somewhat defective in this area. Bernd