On Mon, Mar 7, 2016 at 7:27 AM, Prasad Ghangal <prasad.ghan...@gmail.com> wrote: > On 6 March 2016 at 21:13, Richard Biener <richard.guent...@gmail.com> wrote: >> >> I'll be willing to mentor this. Though I'd rather have us starting from >> scratch and look at having a C-like input language, even piggy-backing on >> the C frontend maybe. > > That's great. I would like to know scope of the project for gsoc so > that I can start preparing for proposal.
In my view (this may require discussion) the GIMPLE FE provides a way to do better unit-testing in GCC as in feeding a GIMPLE pass with specific IL to work with rather than trying to get that into proper shape via a C testcase. Especially making the input IL into that pass stable over the development of GCC is hard. A C-like syntax is prefered, a syntax that is also valid C would be even more prefered so that you can write "torture" testcases that have fixed IL into a specific pass but also run as regular testcases through the whole optimization pipeline. Piggy-backing on the C frontend makes it possible to leave all the details of types and declarations and global initializers as plain C while interpreting function bodies as "GIMPLE" when leaving the frontend. I expect that in the process of completing GIMPLE IL features you'll have to add a few GNU C extensions, mostly for features used by Ada (self-referential types come to my mind). I expect the first thing the project needs to do is add the "tooling" side, signalling the C frontend it should accept GIMPLE (add a -fgimple flag) plus adding a way to input IL into a specific pass (-ftest=<pass> or a function attribute so it affects only a specific function so you can write a testcase driver in plain C and have the actual testcase in a single function). The first actual frontend implementation challenge will then be emitting GIMPLE / CFG / SSA directly which I'd do in the "genericization" phase. Adjustments to how the C FE handles expressions should be made as well, for example I'd remove any promotions done, letting it only literally parse expressions. Maybe statement and expression parsing should be forked directly to not make the C FEs code too unwieldely but as said I'd keep type and decl parsing and its data structures as is. Eventually the dump file format used by GCCs GIMPLE dumps should be changed to be valid GIMPLE FE inputs (and thus valid C inputs). Adjustments mainly need to be done to basic-block labels and PHI nodes. I'd first not think about our on-the-side data too much initially (range info, points-to info, etc). Richard. > >> >> Richard. >> > > -- > Thanks and Regards, > Prasad Ghangal