From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97138 invoked by alias); 9 Feb 2016 21:20:55 -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 97123 invoked by uid 89); 9 Feb 2016 21:20:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=0.4, 0.3, 04, fusionc X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-lf0-f44.google.com Received: from mail-lf0-f44.google.com (HELO mail-lf0-f44.google.com) (209.85.215.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 09 Feb 2016 21:20:53 +0000 Received: by mail-lf0-f44.google.com with SMTP id 78so123635066lfy.3; Tue, 09 Feb 2016 13:20:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=XgShetnemo0GxGcbcbWNnY1HeXfQR1jLrTJvoFlOzzc=; b=Iwnl1466hyCll0OtJMHMHSHVltxvXadc0qVSJA+HrtATPEh6xyNH2xz/OLLCQh0+aq 0FHkcRRnszR5nkqAzoqu6nSbSTnCgtSv3h+Qpc4KYh4mFPmeEZ/WM/5IYyeDV7bar7uW 48pi4RaKNDiA6MdPOpp1MsABL5HHB97V8GF+gwVGyhPUw6pvD6s0gII4Br5xJrfEpa0G rQQLt7q/2KT1xegHkMhplnjurHKXOof5F+6Bv7jZkGm6xDQulk0Pjsn0Ep37MCrLoHGK KxVLtYwvbDwiBMrLLucWAyVdVsXluy+sDoIQcBsVhTVTH6yUSiMy5z7uQ44XUCfKSFtV KFKw== X-Gm-Message-State: AG10YOQ+5QUZhWVU96ml7YnVKD7E6RxrmRTCWrpdhaAvHyy1qiA+jJIdOHMHk/MSm7M9x84XmbPPmJDPPTfAGA== MIME-Version: 1.0 X-Received: by 10.25.142.201 with SMTP id q192mr370110lfd.65.1455052850306; Tue, 09 Feb 2016 13:20:50 -0800 (PST) Received: by 10.114.80.200 with HTTP; Tue, 9 Feb 2016 13:20:50 -0800 (PST) In-Reply-To: <20160209174938.GA17309@ibm-tiger.the-meissners.org> References: <20160209174938.GA17309@ibm-tiger.the-meissners.org> Date: Tue, 09 Feb 2016 21:20:00 -0000 Message-ID: Subject: Re: [PATCH], PR target/68404, Fix PowerPC fusion error From: David Edelsohn To: Michael Meissner , GCC Patches , David Edelsohn , trippels@gcc.gnu.org, "William J. Schmidt" Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-02/txt/msg00649.txt.bz2 On Tue, Feb 9, 2016 at 9:49 AM, Michael Meissner wrote: > This bug fixes PR 68404, which created an insn for the fusion operation when > accessing an array with a large constant offset that the downstream passes > (regrenam in particular don't like). Because fusion in general adds so little > to the performance of power8, I just eliminated the compiler from generating > this case for GCC 6. In the GCC 7 timeframe, I likely will revist fusion for > power9 support. I ran a spec 2006 benchmark suite comparing the current > behavior and the fix for PR 68404, and it was in the noise level (mcf was 1% > slower, others ranged from 0.3% slower to 0.4% faster). > > I did a bootstrap build, including a bootstrap profiled build with LTO (which > is how the problem was found) and it was found. I rewrote 2 of the 3 fusion > tests so that it uses fusion from a medium code toc entry instead of accessing > an array element with a constant index over 65536 bytes. > > Is this patch ok to apply? If you would prefer, I can eliminate the code > inside of the fusion_gpr_addis predicate instead of using #if 0. > > [gcc] > 2016-02-08 Michael Meissner > > PR target/68404 > * config/rs6000/predicates.md (fusion_gpr_addis): Prevent fusing > an ADDIS that adds a pointer to a large constant that sets the > upper16 bits with a load operation. > > [gcc/testsuite] > 2016-02-08 Michael Meissner > > PR target/68404 > * gcc.target/powerpc/fusion.c: Rewrite test to use TOC fusion > instead accessing a really large arrray. > * gcc.target/powerpc/fusion3.c: Likewise. Please remove the code entirely, not #if 0. Okay with that change. Thanks, David