Re: Design Considerations of GIMPLE Front End

[Sebastian Pop <sebpop@gmail.com>]

Hi,

On Mon, May 17, 2010 at 15:15, Sandeep Soni <soni.sandeepb@gmail.com> wrote:
> Hi,
>
> As part of GSoC 2010, I am developing a front end for GIMPLE.
> You can find the basic theme of the project at:
> http://gcc.gnu.org/wiki/GimpleFrontEnd
>
> One of the most important components in this GIMPLE Front End is to
> convert the GIMPLE tuples into text.
> How such a textual representation should be, will obviously dictate
> the design and complexity of the
> subsequent parsing component. So, as per Diego's suggestion, to have a
> view on some of the issues
> I have started this thread.
>
> Following are some of the issues/questions that have come  up:
>
> 1. What should be the format of representation of the GIMPLE tuples in text?
>
>   Ideally, the textual representation should be satisfying two goals:
> Easy to parse and easy for a programmer
>   to write by hand.Considering this,what is the best way in which the
> GIMPLE tuples be represented.
>
>   For example:
>   A textual GIMPLE tuple for the statement a=b+c can be like
>   <GIMPLE_ASSIGN<PLUS_EXPR,a,b,c>>  (As demonstrated by the internal
> manual also).
>   Is such a representation easy to parse?
>
>   The other alternative is to represent the tuples in a C-like syntax
> much like what -fdump-tree-gimple flag does.
>
>   Which is more better? In terms of ease in parsing, intuitiveness
> for a programmer to code by hand etc.
>   Any other alternative?
>
> 2. The most important aspect in the representation is that of types.
> Since there are many possibilities in
>   the types, mapping each in a common representation can be
> difficult. An approach suggested by Diego is to
>   read what fields are read from 'tree' structures and then lay out
> the tuples as follows:
>
>   <TREE_TYPE <name, size, ...>>
>
>   So, we make all the sub-structures into nested tuples. This seems
> to be easy to parse.
>   Again the question: Are there any ideas from anybody about the way
> the types be
>   represented so that the parsing becomes simple?
>
> 3. Finally, what could be the overall structure of such a textual
> gimple file. A possible way could be to have the
>    same structure as the sections encoded in the bytestream.So we can
> have a section for types, symbols,
>    function bodies etc. Such a simple structure will be helpful for
> any programmer and be relatively easy to parse.
>    Any other ideas? arguments against such a structure?
>
>
> So, If there are any alternative ideas to any one of these or
> arguments in favour of /against the ideas presented
> in this mail. Please add it to this thread.

Please have a look at the LLVM language specification:
http://llvm.org/docs/LangRef.html
that should give you a good intuition of what you need to represent
for GIMPLE, and how the LLVM file format is structured.

Would LLVM be acceptable to dump the GIMPLE representation?
In which case you would have an implementation of the pretty printer,
and you would need a parser of LLVM to get that representation back
to GCC.

Sebastian