From patchwork Tue Nov 27 23:53:35 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steven Bosscher X-Patchwork-Id: 202324 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 299DF2C0081 for ; Wed, 28 Nov 2012 10:54:27 +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=1354665268; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: MIME-Version:Received:In-Reply-To:References:From:Date: Message-ID:Subject:To:Cc:Content-Type:Mailing-List:Precedence: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=Mlgajs6alVHJDfTVmvbABt8Qm3E=; b=WAeubnlCGS+PEdq OSU8IuyCkdvzDEb/R1sjIsBzgzNLM+inN1qndAS8On6pH5GxdSUAxesP7ElkCP61 0p1BVgLCbnc6aOkPhWFWthq+SgoREqNT+8xPv8SX2t3n6BHiQsKi5ipkmPeFZPkM wX8xlUJX00UuhFASWhIsc3HyJmaM= 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:Received:MIME-Version:Received:In-Reply-To:References:From:Date:Message-ID:Subject:To:Cc:Content-Type:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=xDCqN4AwqjotAOpKik/yDfz/R7gn+BoPmUF+K8PwBs3WShKREmB+IMWZ2mh9o4 moSmDcRE4qfaagunsoCfwxP1FHt/RO2g4mrtrxSI0uOcFInh8ASKvOUFsKCO51WI sq2RT8/sPWQh0TcB0kRWn4E9DvdAz6P/qoIRh821/4Qtc=; Received: (qmail 9477 invoked by alias); 27 Nov 2012 23:54:25 -0000 Received: (qmail 9468 invoked by uid 22791); 27 Nov 2012 23:54:24 -0000 X-SWARE-Spam-Status: No, hits=-5.2 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 X-Spam-Check-By: sourceware.org Received: from mail-lb0-f175.google.com (HELO mail-lb0-f175.google.com) (209.85.217.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Nov 2012 23:54:17 +0000 Received: by mail-lb0-f175.google.com with SMTP id gg13so7358576lbb.20 for ; Tue, 27 Nov 2012 15:54:15 -0800 (PST) Received: by 10.152.108.42 with SMTP id hh10mr16188200lab.4.1354060455731; Tue, 27 Nov 2012 15:54:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.88.99 with HTTP; Tue, 27 Nov 2012 15:53:35 -0800 (PST) In-Reply-To: <2400864.NhXvZEOEfq@polaris> References: <20121118231540.726263BABA@mailhost.lps.ens.fr> <34723155.BbVgJcJOVM@polaris> <2400864.NhXvZEOEfq@polaris> From: Steven Bosscher Date: Wed, 28 Nov 2012 00:53:35 +0100 Message-ID: Subject: Re: Fix twolf -funroll-loops -O3 miscompilation (a semi-latent web.c bug) To: Eric Botcazou Cc: gcc-patches@gcc.gnu.org, Paolo Bonzini , Dominique Dhumieres , hubicka@ucw.cz, Richard Henderson , Jeff Law X-IsSubscribed: yes 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 Wed, Nov 28, 2012 at 12:47 AM, Eric Botcazou wrote: >> Count me in, too. So let's avoid it: >> >> * gcse.c (struct reg_use): Remove unused struct. >> (gcse_emit_move_after): Do not create REG_EQUAL notes that reference >> the SET_DEST of the instruction the note would be attached to. > > OK (with PR rtl-optimization/55006) if it passes bootstrap & regtest, thanks. Thanks for the quick review. >> And perhaps a bit in emit-rtl.c for good measure? I'll see if/where >> this causes breakage... > > I think this would need to be wrapped in a #ifdef ENABLE_CHECKING/#endif pair. Well, let me first try to make it pass some set of tests. This breaks the compiler in too many places to name right now. Here's the first of what's probably going to be a whole series of patches if I keep hitting this internal_error as often as I am now in my set of cc1-i files... I know: ChangeLog, testing and all that. That's not the point yet. This is just a brain dump, to get this saved in some places safer than the compile farm or (worse) my head ;-) Index: optabs.c =================================================================== --- optabs.c (revision 193394) +++ optabs.c (working copy) @@ -170,9 +170,9 @@ optab_libfunc (optab optab, enum machine If the last insn does not set TARGET, don't do anything, but return 1. - If a previous insn sets TARGET and TARGET is one of OP0 or OP1, - don't add the REG_EQUAL note but return 0. Our caller can then try - again, ensuring that TARGET is not one of the operands. */ + If the last insn or a previous insn sets TARGET and TARGET is one of OP0 + or OP1, don't add the REG_EQUAL note but return 0. Our caller can then + try again, ensuring that TARGET is not one of the operands. */ static int add_equal_note (rtx insns, rtx target, enum rtx_code code, rtx op0, rtx op1) @@ -192,6 +192,12 @@ add_equal_note (rtx insns, rtx target, e if (GET_CODE (target) == ZERO_EXTRACT) return 1; + /* If TARGET is in OP0 or OP1, punt. We'd end up with a note referencing + a value changing in the insn, so the note would be invalid for CSE. */ + if (reg_overlap_mentioned_p (target, op0) + || (op1 && reg_overlap_mentioned_p (target, op1))) + return 0; + for (last_insn = insns; NEXT_INSN (last_insn) != NULL_RTX; last_insn = NEXT_INSN (last_insn)) @@ -207,21 +213,6 @@ add_equal_note (rtx insns, rtx target, e || ! rtx_equal_p (XEXP (SET_DEST (set), 0), target))) return 1; - /* If TARGET is in OP0 or OP1, check if anything in SEQ sets TARGET - besides the last insn. */ - if (reg_overlap_mentioned_p (target, op0) - || (op1 && reg_overlap_mentioned_p (target, op1))) - { - insn = PREV_INSN (last_insn); - while (insn != NULL_RTX) - { - if (reg_set_p (target, insn)) - return 0; - - insn = PREV_INSN (insn); - } - } - if (GET_RTX_CLASS (code) == RTX_UNARY) switch (code) {