This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Design Considerations of GIMPLE Front End
On Tue, May 18, 2010 at 4:30 PM, Basile Starynkevitch
<basile@starynkevitch.net> 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 <soni.sandeepb@gmail.com> wrote:
>> >
>> > > 1. What should be the format of representation of the GIMPLE tuples in
>> > > ? ?text?
>> >
>> > I liked Andrew's suggestion about S-expressions.
>>
>> I can see that for describing types, maybe. ?But isn't that artificially
>> awkward for representing tuple instructions? ?I mean most instructions
>> will look like
>>
>> ? (= i_1 (+ k_1 m_1))
>> or
>> ? (= j_1 (call func arg1 arg2))
>>
>> I don't see how that is much easier to parse compared to
>> ? i_1 = k_1 + m_1
>> ? j_1 = 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
> ? (= (@ "foo.cobol" 23 2) i_1 (+ k_1 m_1)))
> or even
> ? (= (@ "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.