From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5409 invoked by alias); 18 May 2010 14:32:38 -0000 Received: (qmail 5400 invoked by uid 22791); 18 May 2010 14:32:38 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from mail-gw0-f47.google.com (HELO mail-gw0-f47.google.com) (74.125.83.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 18 May 2010 14:32:26 +0000 Received: by gwj19 with SMTP id 19so275647gwj.20 for ; Tue, 18 May 2010 07:32:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.194.12 with SMTP id r12mr8020743ybf.272.1274193144011; Tue, 18 May 2010 07:32:24 -0700 (PDT) Received: by 10.151.105.3 with HTTP; Tue, 18 May 2010 07:32:23 -0700 (PDT) In-Reply-To: <1274193009.9116.13.camel@glinka> References: <1274193009.9116.13.camel@glinka> Date: Tue, 18 May 2010 14:32:00 -0000 Message-ID: Subject: Re: Design Considerations of GIMPLE Front End From: Richard Guenther To: basile@starynkevitch.net Cc: Michael Matz , Diego Novillo , Sandeep Soni , GCC LIST Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2010-05/txt/msg00325.txt.bz2 On Tue, May 18, 2010 at 4:30 PM, Basile Starynkevitch wrote: > On Tue, 2010-05-18 at 15:59 +0200, Michael Matz wrote: >> Hi, >> >> On Tue, 18 May 2010, Diego Novillo wrote: >> >> > On Mon, May 17, 2010 at 16:15, Sandeep Soni = wrote: >> > >> > > 1. What should be the format of representation of the GIMPLE tuples = in >> > > =A0 =A0text? >> > >> > I liked Andrew's suggestion about S-expressions. >> >> I can see that for describing types, maybe. =A0But isn't that artificial= ly >> awkward for representing tuple instructions? =A0I mean most instructions >> will look like >> >> =A0 (=3D i_1 (+ k_1 m_1)) >> or >> =A0 (=3D j_1 (call func arg1 arg2)) >> >> I don't see how that is much easier to parse compared to >> =A0 i_1 =3D k_1 + m_1 >> =A0 j_1 =3D func (arg1, arg2) > > My intuition might be that once a Gimple parser exists, most of its use > would be writing various translators (e.g. external front-ends) to this > syntax, so people might probably code more Gimple-syntax printers than > Gimple-syntax parsers. > > Still, I prefer the Lispy S-expression syntax everywhere -including > Gimple- because it is so simple to define and to implement, and because > GCC MELT already have [almost] the infrastructure for it. > > However, I tend to think that the Gimple syntax would also [at least > optionally] contain the location information, so it would be instead > =A0 (=3D (@ "foo.cobol" 23 2) i_1 (+ k_1 m_1))) > or even > =A0 (=3D (@ "foo.cobol" 23 3) i_1 (+ (@ "foo.cobol" 23 5) k_1 m_1))) > I am using, perhaps wrongly, @ as an "operator" giving the location > information as a file name, line number, column number. I am not sure to > have the syntax right (because I am not sure to remember what exactly > has a location information). Yep, we also need to be able to specify the various flags on gimple statements and information such as alias info. At least if we eventually want to use this as a framework for real unit-testing. So I'm not too concerned about using s-expressions even for the statements. Richard.