On Thu, Mar 10, 2016 at 11:46 AM, Richard Biener <richard.guent...@gmail.com> wrote: > On Wed, Mar 9, 2016 at 8:45 PM, Manuel López-Ibáñez > <lopeziba...@gmail.com> wrote: >> 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? > > Well. I'd like to have a convenient way to write unit-tests for > GIMPLE (SSA) passes > that work good enough which means I have to approximate the GIMPLE IL fed > into a > GIMPLE pass so that I can reproduce a critical situation and keep that stable > over the evolution of GCC (and passes before that pass). > > The most simplistic and pragmatic way was the proposal intruducing -Otest > https://gcc.gnu.org/ml/gcc-patches/2010-08/msg01879.html > > I'd like to have "proper" pass manager modifications to make that work better. > > Then I'd like to be able to re-construct SSA without jumping through hoops > (usually you can get close but if you require copies propagated in a special > way you are basically lost for example). > > Thus my proposal to make the GSoC student attack the unit-testing problem > by doing modifications to the pass manager and "extending" an existing > frontend (C for simplicity). > > It's true that in the ideal world a "GIMPLE frontend" has to work differently > but then to get a 100% GIMPLE frontend you indeed arrive at what LTO > does and then I agree we should attack that from the LTO side and not > develop another thing besides it. But this is a _much_ larger task and > I don't see anyone finishing that. Also keep in mind that the LTO side will > likely simplify a lot by stripping out the ability to stream things that are > only required for debug information (I hopefully will finish LTO early debug > for GCC 7). > > So - can we please somehow focus on the original question about a > GSoC project around the "GIMPLE frontend"? Of course you now can > take Davids promise of spending some development time on this > into consideration. Try drafting something that can be reasonably > accomplished with giving us something to actually use in the GCC 7 > timeframe.
Oh, and rather than trying to define semantics of GIMPLE to write a frontend I'd write the reverse first - a "backend" (aka dumper) plus a simulator. During that effort you can then also do the specification part. You'd produce bytecode plus a textual form. Note that if the textual form is too nice people may view it as a loop-hole into our runtime license exception. Richard. > Thanks, > Richard. > >> Cheers, >> >> Manuel.
