From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7172 invoked by alias); 6 Oct 2016 13:30:24 -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 6998 invoked by uid 89); 6 Oct 2016 13:30:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=settle, readability, kits, pointless 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; Thu, 06 Oct 2016 13:30:21 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (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 BB227C0921AC for ; Thu, 6 Oct 2016 13:30:13 +0000 (UTC) Received: from localhost.localdomain (vpn1-6-105.ams2.redhat.com [10.36.6.105]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u96DUCLu013212; Thu, 6 Oct 2016 09:30:12 -0400 Subject: Re: [PATCH 15/16] RTL frontend (rtl1), on top of dump reader To: David Malcolm , gcc-patches@gcc.gnu.org References: <1475684110-2521-1-git-send-email-dmalcolm@redhat.com> <1475684110-2521-16-git-send-email-dmalcolm@redhat.com> From: Bernd Schmidt Message-ID: Date: Thu, 06 Oct 2016 13:30:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1475684110-2521-16-git-send-email-dmalcolm@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg00375.txt.bz2 On 10/05/2016 06:15 PM, David Malcolm wrote: > +;; MEM[(struct isl_obj *)&obj1] = &isl_obj_map_vtable; > +(insn 1045 0 1046 2 (set (reg:SI 480) > + (high:SI (symbol_ref:SI ("isl_obj_map_vtable") > + [flags 0xc0] > + ))) > + y.c:12702 -1 > + (nil)) > +(insn 1046 1045 1047 2 (set (reg/f:SI 479) > + (lo_sum:SI (reg:SI 480) > + (symbol_ref:SI ("isl_obj_map_vtable") > + [flags 0xc0] > + ))) > + y.c:12702 -1 > + (expr_list:REG_EQUAL (symbol_ref:SI ("isl_obj_map_vtable") > + [flags 0xc0] > + ) > + (nil))) I hate saying this, since you've obviously spent a lot of effort, but I think we're still at a too early stage to construct testcases. One issue that came up while discussing previous patch kits is that the format here is still too verbose, and I'd like to settle on a format first. There's all manner of things that are pointless in a testcase and impede readability: * INSN_UIDs and NEXT/PREV fields (could be constructed from scratch, except for labels) * INSN_CODE_NUMBERs in both textual and number form. * Various (nil) fields * VAR_DECL addresses. What does the RTL reader actually do with MEM_ATTRs? Do these survive the dump/read process? There was also a testcase where virtual regs still occurred with register number, I think it would be best to disallow this and add the ability to parse "(reg:DI virtual-outgoing-args)". Also I think I'd prefer testcases submitted separately from the RTL frontend. It seems we have two different frontend approaches here, one RTL frontend and one modification for the C frontend - which do you prefer? Bernd