Re: [gimplefe] [gsoc16] Gimple Front End Project

[Trevor Saunders <tbsaunde at tbsaunde dot org>]

On Wed, Mar 09, 2016 at 07:45:57PM +0000, Manuel López-Ibáñez wrote:
> On 9 March 2016 at 02:50, Trevor Saunders <tbsaunde@tbsaunde.org> wrote:
> > On Tue, Mar 08, 2016 at 05:12:56PM -0500, Diego Novillo wrote:
> >> This way, implementing a library that supports dealing with GIMPLE
> >> becomes much simpler.  This provides a nice foundation for all kinds
> >> of gimple-oriented tooling in the future.
> >
> > Well, one nice thing about choosing a subset of C as your textual
> > representation of gimple is that all the tools that deal with C already
> > can deal with it, and so you won't really need separate tools for gimple
> > (that would be my theory anyway).
> 
> What tools available for C would be useful for working with gimple IR?

for one thing other compilers can deal with it, that is you can take the
output of a pass and feed it to clang (I'm not totally sure if you could
make phis work somehow, but suspect it might be possible).

> Diego means tools like those available for modifying, compiling and
> verifying LLVM IR and its bytecode representation. Things like
> http://www.cis.upenn.edu/~stevez/vellvm/ and

So, if your IR is C you can use clang to turn it into llvm IR, or run
any C static checker you like on it.

> http://blog.regehr.org/archives/1170 No such thing is available for C
> (nor GIMPLE), because they are not a well-defined IR

Well, C certainly is a well defined language, and I don't see a reason
you can't modify that tool to work with it as easily  as you could for
any other IR than LLVM's.

> (http://lambda-the-ultimate.org/node/715#comment-6526).
> 
> If the gimple IR were a strict subset of GNU C, then by all means
> let's re-use the C FE. However, gimple encodes things that are
> necessary for other languages but are not C. C++ gimple dumps have
> try-finally. Fortran dumps use explicit parentheses "((x))". Surely,
> Ada adds its own quirks to gimple. You can probably represent all this

eh is lowered to something without try / finally pretty early so that
doesn't seem like a big deal, and I can see very little evidence for
PAREN_EXPR effecting optimization so its not clear to me that is an
issue either.

> with a C-looking language plus some large number of new __builtins_
> and __attributes__. At that point you will end up with something that
> is neither a super-set, nor a sub-set of any of the many C variants
> already supported by the C parser. Thus, one would need to
> significantly hack the existing C parser to correctly parse this
> C-looking language, while not breaking any of the things supported by
> the C parser, nor accepting anything not supported by gnu/std C.

I may be wrong, and I'm kind of tempted to prototype something stand
alone just using bison and flex, but I suspect there won't be *that*
many changes especially if you use your own statement parser, and the
changes you would make would mostly be of the form if we are in gimple
mode this construct isn't legal.

> Should the gimple-C parser support promotion rules? If GIMPLE is

I'm not really a gimple expert, but I would tend to say no.

> three-adresses-based, why support expressions with more than two

Well, you might not, or you could decide it is just easier to support it
than not (and that could be handy for writing test cases).

> operands at all? If the dumped IR should be sufficient to stop
> compilation, dump, reload, and continue, then how to represent
> language-specific tree codes that survive until RTL? (perhaps FE trees

I'm under the impression that is mostly only for debug info? and anyway
that's a problem lto has already dealt with.

> leaking into RTL got fixed already and I'm outdated here). What about
> preserving the original source locations? And debug info? All that

if your goal is only unit testing then I think you can just not care
about these, or at least they aren't very important.

Trev

> would need to be handled by a gcc equivalent of LLVM's opt tool. How
> is all that going to be represented in gimple-C?
> 
> Cheers,
> 
> Manuel.