From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99171 invoked by alias); 19 Oct 2016 17:19:16 -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 98099 invoked by uid 89); 19 Oct 2016 17:19:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1291, find_end_label, reader 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; Wed, 19 Oct 2016 17:19:14 +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 23719C056790 for ; Wed, 19 Oct 2016 17:19:13 +0000 (UTC) Received: from vpn-237-201.phx2.redhat.com (vpn-237-201.phx2.redhat.com [10.3.237.201]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9JHJCpP012248; Wed, 19 Oct 2016 13:19:12 -0400 Message-ID: <1476897552.10766.86.camel@redhat.com> Subject: Re: RTL frontend input format again (was Re: [PATCH 15/16] RTL frontend (rtl1), on top of dump reader) From: David Malcolm To: Bernd Schmidt , gcc-patches@gcc.gnu.org Date: Wed, 19 Oct 2016 17:19:00 -0000 In-Reply-To: <3e37a0e5-2293-b0a0-42c0-87ad1464ad8e@redhat.com> References: <1475684110-2521-1-git-send-email-dmalcolm@redhat.com> <1475684110-2521-16-git-send-email-dmalcolm@redhat.com> <1475783612.24366.7.camel@redhat.com> <4ed3a1bd-4efd-d2b8-1755-81ef22db96cc@redhat.com> <1475846819.30303.21.camel@redhat.com> <0f83ea7f-136b-0b66-9068-f693e7b2f8d9@redhat.com> <1476887750.10766.80.camel@redhat.com> <3e37a0e5-2293-b0a0-42c0-87ad1464ad8e@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg01569.txt.bz2 On Wed, 2016-10-19 at 16:41 +0200, Bernd Schmidt wrote: > On 10/19/2016 04:35 PM, David Malcolm wrote: > > > In r241120 I dropped all dumping of the JUMP_LABEL when adding the > > "compact" mode. > > > > I'm now running into an issue with this as I update the __RTL in > > cc1 > > tests to use the new format, since various passes require the > > JUMP_INSNs to have JUMP_LABEL data. > > Isn't it possible to recreate these? In jump.c we have > rebuild_jump_labels, which looks like it'll also compute LABEL_NUSES > which I think we were considering dropping in the output. I already dropped LABEL_NUSES in compact mode in r241120; I think it's possible to regenerate that information. But how would we go about recreating the JUMP_LABEL data? As far as I can tell, it can be set up by reorg.c:make_return_insns via comparison against function_return_label and function_simple_return_label, which are set up by find_end_label; the functions in question are non-trivial, and can lead to extra insns being emitted. Also, in shrink-wrap.c:handle_simple_exit, which has similar state considerations. It seems simpler to serialize this information. Or am I missing something? Thanks Dave