From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 61487 invoked by alias); 29 Nov 2016 16:07:31 -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 61375 invoked by uid 89); 29 Nov 2016 16:07:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=felt 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 ESMTP; Tue, 29 Nov 2016 16:07:29 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (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 56F473D95F; Tue, 29 Nov 2016 16:07:28 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-24.phx2.redhat.com [10.3.116.24]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uATG7RXA016820; Tue, 29 Nov 2016 11:07:28 -0500 Subject: Re: [RFA] Handle target with no length attributes sanely in bb-reorder.c To: Richard Biener References: <67c3fd27-e70b-ff39-0fe2-0d419bd74938@redhat.com> Cc: gcc-patches From: Jeff Law Message-ID: Date: Tue, 29 Nov 2016 16:07:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg02897.txt.bz2 On 11/29/2016 03:23 AM, Richard Biener wrote: > On Mon, Nov 28, 2016 at 10:23 PM, Jeff Law wrote: >> >> >> I was digging into issues around the patches for 78120 when I stumbled upon >> undesirable bb copying in bb-reorder.c on the m68k. >> >> The core issue is that the m68k does not define a length attribute and >> therefore generic code assumes that the length of all insns is 0 bytes. > > What other targets behave like this? ft32, nvptx, mmix, mn10300, m68k, c6x, rl78, vax, ia64, m32c cris has a hack to define a length, even though no attempt is made to make it accurate. The hack specifically calls out that it's to make bb-reorder happy. > >> That in turn makes bb-reorder think it is infinitely cheap to copy basic >> blocks. In the two codebases I looked at (GCC's runtime libraries and >> newlib) this leads to a 10% and 15% undesirable increase in code size. >> >> I've taken a slight variant of this patch and bootstrapped/regression tested >> it on x86_64-linux-gnu to verify sanity as well as built the m68k target >> libraries noted above. >> >> OK for the trunk? > > I wonder if it isn't better to default to a length of 1 instead of zero when > there is no length attribute. There are more users of the length attribute > in bb-reorder.c (and elsewhere as well I suppose). I pondered that as well, but felt it was riskier given we've had a default length of 0 for ports that don't define lengths since the early 90s. It's certainly easy enough to change that default if you'd prefer. I don't have a strong preference either way. Jeff