On 9 March 2016 at 02:50, Trevor Saunders <tbsau...@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? 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 http://blog.regehr.org/archives/1170 No such thing is available for C (nor GIMPLE), because they are not a well-defined IR (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 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. Should the gimple-C parser support promotion rules? If GIMPLE is three-adresses-based, why support expressions with more than two 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 leaking into RTL got fixed already and I'm outdated here). What about preserving the original source locations? And debug info? All that 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.
