From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16343 invoked by alias); 6 Oct 2015 14:33:23 -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 16333 invoked by uid 89); 6 Oct 2015 14:33:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ig0-f170.google.com Received: from mail-ig0-f170.google.com (HELO mail-ig0-f170.google.com) (209.85.213.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 06 Oct 2015 14:33:18 +0000 Received: by igcpb10 with SMTP id pb10so88528616igc.1 for ; Tue, 06 Oct 2015 07:33:16 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.136.129 with SMTP id qa1mr17175409igb.91.1444141996070; Tue, 06 Oct 2015 07:33:16 -0700 (PDT) Received: by 10.36.133.5 with HTTP; Tue, 6 Oct 2015 07:33:16 -0700 (PDT) In-Reply-To: <20151005223627.GA1202@ibm-tiger.the-meissners.org> References: <1443812688.13186.200.camel@otta> <20151005171222.GA21123@ibm-tiger.the-meissners.org> <1444066744.13186.228.camel@otta> <20151005223627.GA1202@ibm-tiger.the-meissners.org> Date: Tue, 06 Oct 2015 14:33:00 -0000 Message-ID: Subject: Re: [PATCH, rs6000] Fix PR target/67808, LRA ICE on double to long double conversion From: David Edelsohn To: Michael Meissner , Peter Bergner , GCC Patches , David Edelsohn , Segher Boessenkool Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-10/txt/msg00577.txt.bz2 On Mon, Oct 5, 2015 at 6:36 PM, Michael Meissner wrote: > Ok, after spending the day on going down the rabbit hole of trying to optimize > just about every, here are my patches. > > Note, I simplified the constraints to eliminate some rare possibilities, like > optimizing converting from double to long double if the double happened to be > in a GPR register and the long double value was stored in memory (but there > never was an optimization for having the double value be in a GPR and the long > double value to also be a GPR). > > I also separated the VSX case from the non-VSX case. This is to simplify things > at the RTL level (non-VSX must load up 0.0 to put into the lower word, while > VSX can use the XXLXOR instruction to clear the register). > > I dropped support in the insns for extending the DFmode value to TFmode that is > located in memory directly. Now, the compiler builds the whole value in FPRs > and then does the store. This simplifies the code somewhat, and SPE/ieeequad > paths require the value to be in registers, which might lead to other lra > bugs. In the case of just doing one conversion in straight line code, it just > changes the register allocation somewhat (allocate 1 TFmode pseudo instead of > 1-2 DFmode psuedos). > > I have bootstrapped the compiler on little endian power8 with no regressions. I > have built the test case with various options (-mlra vs. no -mlra, 32-bit, > 64-bit, power5/power6/power7/power8), and it all builds correctly. > > Is this patch ok to apply to the trunk? > > I would like to apply this patch to GCC 5.x as well. However, in doing the > patch, this patch touches areas that I've been working on for IEEE 128-bit > floating point support, and so the patch will need to be reworked for GCC > 5.x. Is it ok to install in the trunk? > > In addition, I will need to modify this area again with the next IEEE 128-bit > floating point support patch, but I wanted to separate this patch out so that > it could be considered by itself, and back ported to GCC 5.x. > > [gcc] > 2015-10-05 Michael Meissner > Peter Bergner > > PR target/67808 > * config/rs6000/rs6000.md (extenddftf2): In the expander, only > allow registers, but provide insns for the combiner to create for > loads from memory. Separate VSX code from non-VSX code. For > non-VSX code, combine extenddftf2_fprs into extenddftf2 and rename > externaldftf2_internal to externaldftf2_fprs. Reorder constraints > so that registers come before memory operations. Drop support from > converting DFmode to TFmode, if the DFmode value is in a GPR > register, and the TFmode is in memory. > (extenddftf2_fprs): Likewise. > (extenddftf2_internal): Likewise. > (extenddftf2_vsx): Likewise. > (extendsftf2): In the expander, only allow registers, but provide > insns for the combiner to create for stores and loads. > > [gcc/testsuite] > 2015-10-05 Michael Meissner > Peter Bergner > > PR target/67808 > * gcc.target/powerpc/pr67808.c: New test. This is okay for trunk, but can we hold off for GCC 5 and allow things to settle? Thanks, David