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

[Richard Biener <richard dot guenther at gmail dot com>]

On Mon, Mar 7, 2016 at 7:27 AM, Prasad Ghangal <prasad.ghangal@gmail.com> wrote:
> On 6 March 2016 at 21:13, Richard Biener <richard.guenther@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