Design Considerations of GIMPLE Front End

Steven Bosscher
Tue May 18 14:18:00 GMT 2010

On Tue, May 18, 2010 at 4:09 PM, Diego Novillo <> wrote:
> On Tue, May 18, 2010 at 09:59, Michael Matz <> wrote:
>> I don't see how that is much easier to parse compared to
>>  i_1 = k_1 + m_1
>>  j_1 = func (arg1, arg2)
> Well, it would make the parser almost trivial to implement.  But you
> have a point, the only structurally complex objects we need to parse
> are type declarations.  Everything else should have very uniform
> syntax.
>> The nice thing with tuples is that there's always only one operator, and
>> hence no ambiguity in precedence that needs to be resolved or explicitely
>> encoded via a list structure.
> That's true.
>> Or is the format also intended to be able to represent GENERIC, i.e.
>> deeply nested structures?
> No, just gimple.

IMHO, ideally we would have a syntax that is human readable and human
writable. S-expressions are not as easy to read for me as something
that resembles C.

Related subject: Is it possible to have a formal grammar of some kind
for, say, bison? It would be nice if we can generate different tools
from one grammar, e.g. a GIMPLE front end, a syntax checker, maybe
static analyzers, etc. If you make a reader that already constructs
the gimple data structures, it will be harder to construct multiple
tools on top of it that are independent of libbackend.


More information about the Gcc mailing list