From patchwork Tue Oct 16 06:40:21 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tom de Vries X-Patchwork-Id: 191729 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 AF67F2C009A for ; Tue, 16 Oct 2012 17:40:52 +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=1350974453; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC: Subject:Content-Type:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=cVKXEcW6kKnURLPaWw94WNJJx78=; b=lxfHKxNpMyI+okt cwuYL9B2RWJxBvwtR4CZkA97psS4DuQiIsItuWRMz6vUsfk12+/bl2jI+rp9bFBR l+d0qpI1amceSGOrW6WR9O+Y1axDPNgJEJRWwITrBYGjI5Nf7ZTmKbIfgm+KMddg tjuEjenAVVgl0r9k3C4nrl/F3OTw= 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:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=VLdLAAc8KvspFDJOSAF1Jh9tNWeih844dVJ4pLqOY83b8XHDvUqKMysLIvjMLi O+UnQHj0Yj6Ju8L5zLz/ErMCYudn7ReQEQnA1v8YdzK+IkLkBAA6eLs1hXTkqXPg zKVWKNtejkTx9tnf1byqi9q4d7l7vLoRlLvJVNaNtIYbA=; Received: (qmail 32468 invoked by alias); 16 Oct 2012 06:40:47 -0000 Received: (qmail 32388 invoked by uid 22791); 16 Oct 2012 06:40:46 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_HOSTKARMA_W, RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 16 Oct 2012 06:40:40 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1TO0pS-0002w6-R8 from Tom_deVries@mentor.com ; Mon, 15 Oct 2012 23:40:38 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Oct 2012 23:40:38 -0700 Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Tue, 16 Oct 2012 07:40:34 +0100 Message-ID: <507D0155.6090008@mentor.com> Date: Tue, 16 Oct 2012 08:40:21 +0200 From: Tom de Vries User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Jakub Jelinek CC: "gcc-patches@gcc.gnu.org" Subject: [PATCH] Stop looping in move_by_pieces loops when there's no more data to process 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 Jakub, I've noticed that the move_by_pieces loops keep iterating after there's no more data to process. I've added this assert to trigger an example in a gcc build: ... ... It triggers while compiling __gcov_execle. After l is 0, we still enter the loop until we run out of modes to try: ... Breakpoint 2, move_by_pieces_ninsns (l=24, align=64, max_size=9) at expr.c:1025 1025 unsigned HOST_WIDE_INT n_insns = 0; (gdb) n 1027 align = alignment_for_piecewise_move (MOVE_MAX_PIECES, align); (gdb) 1029 while (max_size > 1) (gdb) 1034 gcc_assert (l > 0); (gdb) 1036 mode = widest_int_mode_for_size (max_size); (gdb) 1038 if (mode == VOIDmode) (gdb) 1041 icode = optab_handler (mov_optab, mode); (gdb) 1042 if (icode != CODE_FOR_nothing && align >= GET_MODE_ALIGNMENT (mode)) (gdb) 1043 n_insns += l / GET_MODE_SIZE (mode), l %= GET_MODE_SIZE (mode); (gdb) 1045 max_size = GET_MODE_SIZE (mode); (gdb) 1029 while (max_size > 1) (gdb) p l $3 = 0 (gdb) p max_size $4 = 8 (gdb) n 1034 gcc_assert (l > 0); (gdb) ... This patch fixes that in this loop, and other move_by_pieces loops. Bootstrapped and reg-tested on x86_64. OK for trunk? Thanks, - Tom 2012-10-16 Tom de Vries * expr.c (move_by_pieces, move_by_pieces_ninsns, can_store_by_pieces) (store_by_pieces_1): Don't enter loop when no more data is left. Index: gcc/expr.c =================================================================== --- gcc/expr.c (revision 191792) +++ gcc/expr.c (working copy) @@ -966,7 +966,7 @@ move_by_pieces (rtx to, rtx from, unsign /* First move what we can in the largest integer mode, then go to successively smaller modes. */ - while (max_size > 1) + while (max_size > 1 && data.len > 0) { enum machine_mode mode = widest_int_mode_for_size (max_size); @@ -1026,7 +1026,7 @@ move_by_pieces_ninsns (unsigned HOST_WID align = alignment_for_piecewise_move (MOVE_MAX_PIECES, align); - while (max_size > 1) + while (max_size > 1 && l > 0) { enum machine_mode mode; enum insn_code icode; @@ -2417,7 +2417,7 @@ can_store_by_pieces (unsigned HOST_WIDE_ { l = len; max_size = STORE_MAX_PIECES + 1; - while (max_size > 1) + while (max_size > 1 && l > 0) { mode = widest_int_mode_for_size (max_size); @@ -2612,7 +2612,7 @@ store_by_pieces_1 (struct store_by_piece /* First store what we can in the largest integer mode, then go to successively smaller modes. */ - while (max_size > 1) + while (max_size > 1 && data->len > 0) { enum machine_mode mode = widest_int_mode_for_size (max_size);