[gimplefe] [gsoc16] Gimple Front End Project

[gimplefe] [gsoc16] Gimple Front End Project

[Prasad Ghangal]

Hi!

I am interested to work on Gimple FE project for gsoc16. I would like
to know the scope of the project for gsoc. Also anyone like to mentor
me for the project?




Thanks and Regards,
Prasad Ghangal

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

[Prasad Ghangal]

Hi!

On stackoverflow
http://stackoverflow.com/questions/21660563/can-gcc-compile-gimple,
they said GIMPLE FE project is dead. Please let me know if I can work
on it for gsoc.

On 5 March 2016 at 03:01, Prasad Ghangal <prasad.ghangal@gmail.com> wrote:
> Hi!
>
> I am interested to work on Gimple FE project for gsoc16. I would like
> to know the scope of the project for gsoc. Also anyone like to mentor
> me for the project?
>
>
>
>
> Thanks and Regards,
> Prasad Ghangal



-- 
Thanks and Regards,
Prasad Ghangal

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

[Trevor Saunders]

On Sun, Mar 06, 2016 at 04:33:30PM +0530, Prasad Ghangal wrote:
> Hi!
> 
> On stackoverflow
> http://stackoverflow.com/questions/21660563/can-gcc-compile-gimple,
> they said GIMPLE FE project is dead. Please let me know if I can work
> on it for gsoc.

Well, nobody has worked on it for a long time, but I think there's a
number of people who'd like to see something like that get finished.  I
don't know that I'm capable of mentoring this on my own, but I'd be
willing to help out, and istr David malcolm was talking about working on
the gimple fe for gcc 7.

Trev

> 
> On 5 March 2016 at 03:01, Prasad Ghangal <prasad.ghangal@gmail.com> wrote:
> > Hi!
> >
> > I am interested to work on Gimple FE project for gsoc16. I would like
> > to know the scope of the project for gsoc. Also anyone like to mentor
> > me for the project?
> >
> >
> >
> >
> > Thanks and Regards,
> > Prasad Ghangal
> 
> 
> 
> -- 
> Thanks and Regards,
> Prasad Ghangal

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

[Diego Novillo]

On Sun, Mar 6, 2016 at 6:03 AM, Prasad Ghangal <prasad.ghangal@gmail.com> wrote:
> Hi!
>
> On stackoverflow
> http://stackoverflow.com/questions/21660563/can-gcc-compile-gimple,
> they said GIMPLE FE project is dead. Please let me know if I can work
> on it for gsoc.

I stopped working on GIMPLE FE a long time ago.  Even though I'm no
longer doing any GCC work, this is still one project I would like to
see completed.  Unfortunately, I've been away for long enough that I
would not be an effective mentor for this project.

I'm sure you'll find enough interest in the GCC community.  Several
folks would be able to mentor you with this.


Diego.

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

[Richard Biener]

On March 6, 2016 3:45:37 PM GMT+01:00, Diego Novillo <dnovillo@google.com> wrote:
>On Sun, Mar 6, 2016 at 6:03 AM, Prasad Ghangal
><prasad.ghangal@gmail.com> wrote:
>> Hi!
>>
>> On stackoverflow
>> http://stackoverflow.com/questions/21660563/can-gcc-compile-gimple,
>> they said GIMPLE FE project is dead. Please let me know if I can work
>> on it for gsoc.
>
>I stopped working on GIMPLE FE a long time ago.  Even though I'm no
>longer doing any GCC work, this is still one project I would like to
>see completed.  Unfortunately, I've been away for long enough that I
>would not be an effective mentor for this project.
>
>I'm sure you'll find enough interest in the GCC community.  Several
>folks would be able to mentor you with this.

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.

Richard.

>
>Diego.

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

[Prasad Ghangal]

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.

>
> Richard.
>

-- 
Thanks and Regards,
Prasad Ghangal

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

[Richard Biener]

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

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

[David Malcolm]

On Mon, 2016-03-07 at 13:26 +0100, Richard Biener wrote:
> 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.

I've been looking at the gimple FE recently, at the above is precisely
my own motivation.  Much of our current testing involves taking a C
file, running the pass pipeline over it, and then verifying properties
of one specific pass, and this worries me, since all of the intervening
passes can change, and thus can change the effective input seen by the
pass we were hoping to test, invalidating the test case.

As part of the "unit tests" idea:
  v1: https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00765.html
  v2: https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01224.html
  v3: https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02947.html
I attempted to write unit tests for specific passes.  The closest I got
was this, which built the function in tree form, then gimplified it,
then expanded it:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02954.html

Whilst writing this I attempted to build test cases by constructing IR
directly via API calls, but it became clear to me that that approach
isn't a good one: it's very verbose, and would tie us to the internal
API.

(I think the above patch kit has merit for testing things other than
passes, as a "-fself-test" option, which I want to pursue for gcc 7).

So for testing specific passes, I'd much rather have an input format
for testing individual passes that:
  * can be easily generated by GCC from real test cases
  * ability to turn into unit tests, which implies:
    * human-readable and editable
  * compatibility and stability: can load gcc 7 test cases into gcc 8;
have e.g. gcc 6 generate test cases
  * roundtrippable: can load the format, then save out the IR, and get
the same file, for at least some subset of the format (consider e.g.
location data: explicit location data can be roundtripped, implicit
location data not so much).

...which suggests that we'd want to use gimple dumps as the input
format to a test framework - which leads naturally to the idea of a
gimple frontend.

I'm thinking of something like a testsuite/gimple.dg subdirectory full
of gimple dumps.

We could have a new kind of diagnostic, a "remark", with DejaGnu
directives to detect for it e.g.

  a_5 = b_1 * c_2;  /* { dg-remark "propagated constant; became a_5 =
b_1 * 3" } */

or whatnot. 

I see our dumpfiles as being something aimed at us, whereas remarks
could be aimed at sophisticated end-users; they would be enabled on a
per-pass basis, or perhaps for certain topics (e.g. vectorization) and
could look something like:

foo.c:27:10: remark: loop is not vectorizable since the iterator can be
modified... [-Rvectorization]
foo.c.35:20: ...here

or similar, where the user passed say "-Rvectorization" as a command
line option to request more info on vectorization, and our test suites
could do this.

As a thought-experiment, consider that as well as cc1 etc, we could
have an executable for every pass.  Then you could run individual
passes e.g.:

  $ run-vrp foo.gimple -o bar.gimple
  $ run-switchconv quux.gimple -o baz.gimple

etc.   (I'm not convinced that it makes sense to split things up so
much, but I find it useful for inspiration, for getting ideas about the
things that we could do if we had that level of modularity, especially
from a testing perpective).


FWIW I started looking at the existing gimple FE branch last week.  It
implements a parser for a tuple syntax, rather than the C-like syntax.

The existing parser doeesn't actually generate any gimple IR
internally, it just syntax-checks the input file.  Building IR
internally seemed like a good next step, since I'm sure there are lots
of state issues to sort out.  So I started looking at implementing a
testsuite/gimple.dg/roundtrip subdirectory: the idea is that this would
be full of gimple dumps; the parser would read them in, and then (with
a flag supplied by roundtrip.exp) would write them out, and
roundtrip.exp would compare input to output and require them to be
identical.  I got as far as (partially) building a GIMPLE_ASSIGN
internally when parsing a file containing one.

That said, I don't care for the tuple syntax in the existing gimple
dump format; I'd prefer a C-like syntax.

My thought was to hack up the existing gimple FE branch to change the
parser to accept a more C-like syntax, but...

> 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.

...it sounds like you have a radically different implementation idea,
in which the gimple frontend effectively becomes part of the C
frontend, with some different behaviors.

> 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.

Hope this is constructive
Dave

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

[Trevor Saunders]

On Mon, Mar 07, 2016 at 11:33:55AM -0500, David Malcolm wrote:
> On Mon, 2016-03-07 at 13:26 +0100, Richard Biener wrote:
> > 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.
> 
> I've been looking at the gimple FE recently, at the above is precisely
> my own motivation.  Much of our current testing involves taking a C
> file, running the pass pipeline over it, and then verifying properties
> of one specific pass, and this worries me, since all of the intervening
> passes can change, and thus can change the effective input seen by the
> pass we were hoping to test, invalidating the test case.
> 
> As part of the "unit tests" idea:
>   v1: https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00765.html
>   v2: https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01224.html
>   v3: https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02947.html
> I attempted to write unit tests for specific passes.  The closest I got
> was this, which built the function in tree form, then gimplified it,
> then expanded it:
> https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02954.html
> 
> Whilst writing this I attempted to build test cases by constructing IR
> directly via API calls, but it became clear to me that that approach
> isn't a good one: it's very verbose, and would tie us to the internal
> API.
> 
> (I think the above patch kit has merit for testing things other than
> passes, as a "-fself-test" option, which I want to pursue for gcc 7).
> 
> So for testing specific passes, I'd much rather have an input format
> for testing individual passes that:
>   * can be easily generated by GCC from real test cases
>   * ability to turn into unit tests, which implies:
>     * human-readable and editable
>   * compatibility and stability: can load gcc 7 test cases into gcc 8;
> have e.g. gcc 6 generate test cases
>   * roundtrippable: can load the format, then save out the IR, and get
> the same file, for at least some subset of the format (consider e.g.
> location data: explicit location data can be roundtripped, implicit
> location data not so much).
> 
> ...which suggests that we'd want to use gimple dumps as the input
> format to a test framework - which leads naturally to the idea of a
> gimple frontend.

Assuming you mean the format from -fdump-tree-* that's a kind of C like
language so argues against using tooples like the existing gimple-fe
branch.

> I'm thinking of something like a testsuite/gimple.dg subdirectory full
> of gimple dumps.
> 
> We could have a new kind of diagnostic, a "remark", with DejaGnu
> directives to detect for it e.g.
> 
>   a_5 = b_1 * c_2;  /* { dg-remark "propagated constant; became a_5 =
> b_1 * 3" } */
> 
> or whatnot. 
> 
> I see our dumpfiles as being something aimed at us, whereas remarks
> could be aimed at sophisticated end-users; they would be enabled on a
> per-pass basis, or perhaps for certain topics (e.g. vectorization) and
> could look something like:

That's interesting, as you sort of note the other option is to just scan
the output dump for what you intend to check.  The remark idea is
interesting though, the -Wsuggest-final-{method,type} warnings are
trying to be that, and istr something else like that.

> foo.c:27:10: remark: loop is not vectorizable since the iterator can be
> modified... [-Rvectorization]
> foo.c.35:20: ...here
> 
> or similar, where the user passed say "-Rvectorization" as a command
> line option to request more info on vectorization, and our test suites
> could do this.
> 
> As a thought-experiment, consider that as well as cc1 etc, we could
> have an executable for every pass.  Then you could run individual
> passes e.g.:
> 
>   $ run-vrp foo.gimple -o bar.gimple
>   $ run-switchconv quux.gimple -o baz.gimple
> 
> etc.   (I'm not convinced that it makes sense to split things up so
> much, but I find it useful for inspiration, for getting ideas about the
> things that we could do if we had that level of modularity, especially
> from a testing perpective).

yeah, though if you got rid of most / all of the other global state
maybe it wouldn't be hard?  but yeah it doesn't seem like the most
important thing either.

> FWIW I started looking at the existing gimple FE branch last week.  It
> implements a parser for a tuple syntax, rather than the C-like syntax.
> 
> The existing parser doeesn't actually generate any gimple IR
> internally, it just syntax-checks the input file.  Building IR
> internally seemed like a good next step, since I'm sure there are lots
> of state issues to sort out.  So I started looking at implementing a
> testsuite/gimple.dg/roundtrip subdirectory: the idea is that this would
> be full of gimple dumps; the parser would read them in, and then (with
> a flag supplied by roundtrip.exp) would write them out, and
> roundtrip.exp would compare input to output and require them to be
> identical.  I got as far as (partially) building a GIMPLE_ASSIGN
> internally when parsing a file containing one.
> 
> That said, I don't care for the tuple syntax in the existing gimple
> dump format; I'd prefer a C-like syntax.

agreed, and being compatable with the existing dumps suggests it too.

> My thought was to hack up the existing gimple FE branch to change the
> parser to accept a more C-like syntax, but...
> 
> > 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.
> 
> ...it sounds like you have a radically different implementation idea,
> in which the gimple frontend effectively becomes part of the C
> frontend, with some different behaviors.

Well, it seems like if the existing gimple-fe is basically just a parser
for a language we don't like there isn't much value in building off of
it instead of writing something from scratch.

Being compatable with C probably with some builtins to do SSA stuff
seems pretty nice.  I worry some about the work to avoid folding and
stuff, but sharing code with the c-family languages seems good if we
can.

Trev


> 
> > 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.
> 
> Hope this is constructive
> Dave

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

[Manuel López-Ibáñez]

On 08/03/16 00:24, Trevor Saunders wrote:
>> ...which suggests that we'd want to use gimple dumps as the input
>> format to a test framework - which leads naturally to the idea of a
>> gimple frontend.
>
> Assuming you mean the format from -fdump-tree-* that's a kind of C like
> language so argues against using tooples like the existing gimple-fe
> branch.

The dumps contain a lot of (sometimes optional) unstructured information. For 
example, they show both the result of the pass and (arbitrarily unstructured) 
messages about what the pass is doing.

Wouldn't it be better to get the dumps in a more structured form (e.g., 
separating IR from debug messages) before doing this?

> That's interesting, as you sort of note the other option is to just scan
> the output dump for what you intend to check.  The remark idea is
> interesting though, the -Wsuggest-final-{method,type} warnings are
> trying to be that, and istr something else like that.
>
>> foo.c:27:10: remark: loop is not vectorizable since the iterator can be
>> modified... [-Rvectorization]
>> foo.c.35:20: ...here
>>
>> or similar, where the user passed say "-Rvectorization" as a command
>> line option to request more info on vectorization, and our test suites
>> could do this.

Isn't this what -fopt-info does? 
https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html

>> As a thought-experiment, consider that as well as cc1 etc, we could
>> have an executable for every pass.  Then you could run individual
>> passes e.g.:
>>
>>    $ run-vrp foo.gimple -o bar.gimple
>>    $ run-switchconv quux.gimple -o baz.gimple
>>
>> etc.   (I'm not convinced that it makes sense to split things up so
>> much, but I find it useful for inspiration, for getting ideas about the
>> things that we could do if we had that level of modularity, especially
>> from a testing perpective).

You can have a FE that reads gimple and outputs gimple, and allows to enable 
any individual optimization flags without an -O option, such as:

$ gimple -ftree-vrp foo.gimple -o bar.gimple

The driver could also learn about *.gimple files in order to invoke the gimple 
front-end. This way, you can use the same option names for the gimple FE and 
the rest of GCC.

Of course, ideally, the pass manager would be all modular, based on 
dependencies and re-configurable like 
http://llvm.org/docs/CommandGuide/opt.html I wonder how far away is GCC's 
middle-end from being able to do that.

>>> 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.
>>
>> ...it sounds like you have a radically different implementation idea,
>> in which the gimple frontend effectively becomes part of the C
>> frontend, with some different behaviors.
>
> Well, it seems like if the existing gimple-fe is basically just a parser
> for a language we don't like there isn't much value in building off of
> it instead of writing something from scratch.
>
> Being compatable with C probably with some builtins to do SSA stuff
> seems pretty nice.  I worry some about the work to avoid folding and
> stuff, but sharing code with the c-family languages seems good if we
> can.

Sharing code is good. Extending the C (or C++?) FE to also parse gimple-C seems 
a terrible idea because how badly non-modular GCC is already. It seems better 
to make gimple-C a c-family language, so it can share functions with other 
C-family languages, but fork every function/data structure that requires 
modification.

Moreover, such a gimple-C parser should be significantly simpler than a full 
featured C parser if gimple-C is assumed to be in SSA form and all loops 
lowered to goto and the syntax is only based on modern C.

Cheers,

	Manuel.

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

[Richard Biener]

On March 8, 2016 4:42:41 PM GMT+01:00, "Manuel López-Ibáñez" <lopezibanez@gmail.com> wrote:
>On 08/03/16 00:24, Trevor Saunders wrote:
>>> ...which suggests that we'd want to use gimple dumps as the input
>>> format to a test framework - which leads naturally to the idea of a
>>> gimple frontend.
>>
>> Assuming you mean the format from -fdump-tree-* that's a kind of C
>like
>> language so argues against using tooples like the existing gimple-fe
>> branch.
>
>The dumps contain a lot of (sometimes optional) unstructured
>information. For 
>example, they show both the result of the pass and (arbitrarily
>unstructured) 
>messages about what the pass is doing.
>
>Wouldn't it be better to get the dumps in a more structured form (e.g.,
>
>separating IR from debug messages) before doing this?

I'd say a dump modifier -il to make it dump IL only (maybe into a different file) plus required global info such as types would be enough.

>> That's interesting, as you sort of note the other option is to just
>scan
>> the output dump for what you intend to check.  The remark idea is
>> interesting though, the -Wsuggest-final-{method,type} warnings are
>> trying to be that, and istr something else like that.
>>
>>> foo.c:27:10: remark: loop is not vectorizable since the iterator can
>be
>>> modified... [-Rvectorization]
>>> foo.c.35:20: ...here
>>>
>>> or similar, where the user passed say "-Rvectorization" as a command
>>> line option to request more info on vectorization, and our test
>suites
>>> could do this.
>
>Isn't this what -fopt-info does? 
>https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html

Yes.

>>> As a thought-experiment, consider that as well as cc1 etc, we could
>>> have an executable for every pass.  Then you could run individual
>>> passes e.g.:
>>>
>>>    $ run-vrp foo.gimple -o bar.gimple
>>>    $ run-switchconv quux.gimple -o baz.gimple
>>>
>>> etc.   (I'm not convinced that it makes sense to split things up so
>>> much, but I find it useful for inspiration, for getting ideas about
>the
>>> things that we could do if we had that level of modularity,
>especially
>>> from a testing perpective).
>
>You can have a FE that reads gimple and outputs gimple, and allows to
>enable 
>any individual optimization flags without an -O option, such as:
>
>$ gimple -ftree-vrp foo.gimple -o bar.gimple
>
>The driver could also learn about *.gimple files in order to invoke the
>gimple 
>front-end. This way, you can use the same option names for the gimple
>FE and 
>the rest of GCC.
>
>Of course, ideally, the pass manager would be all modular, based on 
>dependencies and re-configurable like 
>http://llvm.org/docs/CommandGuide/opt.html I wonder how far away is
>GCC's 
>middle-end from being able to do that.

For any kind of unit testing you need to develop some pass manager support.

>>>> 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.
>>>
>>> ...it sounds like you have a radically different implementation
>idea,
>>> in which the gimple frontend effectively becomes part of the C
>>> frontend, with some different behaviors.
>>
>> Well, it seems like if the existing gimple-fe is basically just a
>parser
>> for a language we don't like there isn't much value in building off
>of
>> it instead of writing something from scratch.
>>
>> Being compatable with C probably with some builtins to do SSA stuff
>> seems pretty nice.  I worry some about the work to avoid folding and
>> stuff, but sharing code with the c-family languages seems good if we
>> can.
>
>Sharing code is good. Extending the C (or C++?) FE to also parse
>gimple-C seems 
>a terrible idea because how badly non-modular GCC is already. It seems
>better 
>to make gimple-C a c-family language, so it can share functions with
>other 
>C-family languages, but fork every function/data structure that
>requires 
>modification.
>
>Moreover, such a gimple-C parser should be significantly simpler than a
>full 
>featured C parser if gimple-C is assumed to be in SSA form and all
>loops 
>lowered to goto and the syntax is only based on modern C.

True.  But as far as a GSoC scoped project goes I strongly suggest to re-use the C FE to save you from paesing declarations and the required GENERIC building.

Also note my suggestion that all GIMPLE sources should be valid C as well it would be unfortunate to lose the option to torture unit tests.

Richard.

>Cheers,
>
>	Manuel.

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

[David Malcolm]

On Tue, 2016-03-08 at 16:56 +0100, Richard Biener wrote:
> On March 8, 2016 4:42:41 PM GMT+01:00, "Manuel López-Ibáñez" <
> lopezibanez@gmail.com> wrote:
> > On 08/03/16 00:24, Trevor Saunders wrote:
> > > > ...which suggests that we'd want to use gimple dumps as the
> > > > input
> > > > format to a test framework - which leads naturally to the idea
> > > > of a
> > > > gimple frontend.
> > > 
> > > Assuming you mean the format from -fdump-tree-* that's a kind of
> > > C
> > like
> > > language so argues against using tooples like the existing gimple
> > > -fe
> > > branch.
> > 
> > The dumps contain a lot of (sometimes optional) unstructured
> > information. For 
> > example, they show both the result of the pass and (arbitrarily
> > unstructured) 
> > messages about what the pass is doing.
> > 
> > Wouldn't it be better to get the dumps in a more structured form
> > (e.g.,
> > 
> > separating IR from debug messages) before doing this?
> 
> I'd say a dump modifier -il to make it dump IL only (maybe into a
> different file) plus required global info such as types would be
> enough.
> 
> > > That's interesting, as you sort of note the other option is to
> > > just
> > scan
> > > the output dump for what you intend to check.  The remark idea is
> > > interesting though, the -Wsuggest-final-{method,type} warnings
> > > are
> > > trying to be that, and istr something else like that.
> > > 
> > > > foo.c:27:10: remark: loop is not vectorizable since the
> > > > iterator can
> > be
> > > > modified... [-Rvectorization]
> > > > foo.c.35:20: ...here
> > > > 
> > > > or similar, where the user passed say "-Rvectorization" as a
> > > > command
> > > > line option to request more info on vectorization, and our test
> > suites
> > > > could do this.
> > 
> > Isn't this what -fopt-info does? 
> > https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html
> 
> Yes.

One difference is that in this proposal, the output is emitted as a
diagnostic, rather than to a file.

FWIW, I find those existing options to be very fiddly to use (and
they're categorized as "GCC Developer Options").

> > > > As a thought-experiment, consider that as well as cc1 etc, we
> > > > could
> > > > have an executable for every pass.  Then you could run
> > > > individual
> > > > passes e.g.:
> > > > 
> > > >    $ run-vrp foo.gimple -o bar.gimple
> > > >    $ run-switchconv quux.gimple -o baz.gimple
> > > > 
> > > > etc.   (I'm not convinced that it makes sense to split things
> > > > up so
> > > > much, but I find it useful for inspiration, for getting ideas
> > > > about
> > the
> > > > things that we could do if we had that level of modularity,
> > especially
> > > > from a testing perpective).
> > 
> > You can have a FE that reads gimple and outputs gimple, and allows
> > to
> > enable 
> > any individual optimization flags without an -O option, such as:
> > 
> > $ gimple -ftree-vrp foo.gimple -o bar.gimple
> > 
> > The driver could also learn about *.gimple files in order to invoke
> > the
> > gimple 
> > front-end. This way, you can use the same option names for the
> > gimple
> > FE and 
> > the rest of GCC.
> > 
> > Of course, ideally, the pass manager would be all modular, based on
> > dependencies and re-configurable like 
> > http://llvm.org/docs/CommandGuide/opt.html I wonder how far away is
> > GCC's 
> > middle-end from being able to do that.
> 
> For any kind of unit testing you need to develop some pass manager
> support.

(nods)

> > > > > 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.
> > > > 
> > > > ...it sounds like you have a radically different implementation
> > idea,
> > > > in which the gimple frontend effectively becomes part of the C
> > > > frontend, with some different behaviors.
> > > 
> > > Well, it seems like if the existing gimple-fe is basically just a
> > parser
> > > for a language we don't like there isn't much value in building
> > > off
> > of
> > > it instead of writing something from scratch.
> > > 
> > > Being compatable with C probably with some builtins to do SSA
> > > stuff
> > > seems pretty nice.  I worry some about the work to avoid folding
> > > and
> > > stuff, but sharing code with the c-family languages seems good if
> > > we
> > > can.
> > 
> > Sharing code is good. Extending the C (or C++?) FE to also parse
> > gimple-C seems 
> > a terrible idea because how badly non-modular GCC is already. It
> > seems
> > better 
> > to make gimple-C a c-family language, so it can share functions
> > with
> > other 
> > C-family languages, but fork every function/data structure that
> > requires 
> > modification.
> > 
> > Moreover, such a gimple-C parser should be significantly simpler
> > than a
> > full 
> > featured C parser if gimple-C is assumed to be in SSA form and all
> > loops 
> > lowered to goto and the syntax is only based on modern C.
> 
> True.  But as far as a GSoC scoped project goes I strongly suggest to
> re-use the C FE to save you from paesing declarations and the
> required GENERIC building.

FWIW I was thinking of spending a significant chunk of $DAYJOB in gcc 7
stage 1 hacking on a gimple FE, for the purposes of unit testing of
passes, rather that it being "just" a GSoC scoped project.

> Also note my suggestion that all GIMPLE sources should be valid C as
> well it would be unfortunate to lose the option to torture unit
> tests.

This is possibly a silly question, but why would a custom C-like FE for
a language that isn't quite C rule out torturing unit tests?  Can't we
inject the gimple at the stage it was generated, and then supply
various -O options to run various combinations of passes?

If we did it directly using the C frontend, from an implementation
point of view, would it be something like this:
  * the modified c frontend would build trees with lang-specific nodes
(as before)
  * it only accepts sufficiently "flat" trees that conform to gimple
statements (issuing errors for e.g. nested expressions)
  * gimple statements would then be generated directly from those flat
trees, supporting the various stages of gimple:
    * before CFG, 
    * with CFG but before SSA
    * CFG + SSA
    so that we can unit-test all of the gimple passes including e.g.
unit-testing the creation of CFG and conversion to SSA
  * some kind of new builtin for phi nodes
?

(Though hacking up the C frontend might be a suitable way to prototype
a dedicated gimple frontend; runs into issues of having them diverge. 
 I don't know how much we'd want in common vs how much has to be
different)

(potentially we could define a subset of e.g. C99 that would be
acceptable as gimple.  I don't know if that's helpful)


Dave

> Richard.
> 
> > Cheers,
> > 
> > 	Manuel.
> 
> 

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

[Mikhail Maltsev]

On 03/08/2016 06:56 PM, Richard Biener wrote:
>> The dumps contain a lot of (sometimes optional) unstructured
>> information. For 
>> example, they show both the result of the pass and (arbitrarily
>> unstructured) 
>> messages about what the pass is doing.
>>
>> Wouldn't it be better to get the dumps in a more structured form (e.g.,
>>
>> separating IR from debug messages) before doing this?
> 
> I'd say a dump modifier -il to make it dump IL only (maybe into a different file) plus required global info such as types would be enough.
Why not just support comments in GIMPLE FE and output all unstructured pass
information inside them? In fact, some stuff is already wrapped into ";;"-style
comments, like this:

;; Function fn1 (null)
;; enabled by -tree-original

You could just change it to use C++-style comments (//), which C-family
frontends already understand.

> 
> Also note my suggestion that all GIMPLE sources should be valid C as well it would be unfortunate to lose the option to torture unit tests.
> 
I wonder how will this work with SSA form?

-- 
Regards,
    Mikhail Maltsev

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

[Trevor Saunders]

On Tue, Mar 08, 2016 at 11:47:48AM -0500, David Malcolm wrote:
> On Tue, 2016-03-08 at 16:56 +0100, Richard Biener wrote:
> > On March 8, 2016 4:42:41 PM GMT+01:00, "Manuel López-Ibáñez" <
> > lopezibanez@gmail.com> wrote:
> > > On 08/03/16 00:24, Trevor Saunders wrote:
> > > > > ...which suggests that we'd want to use gimple dumps as the
> > > > > input
> > > > > format to a test framework - which leads naturally to the idea
> > > > > of a
> > > > > gimple frontend.
> > > > 
> > > > Assuming you mean the format from -fdump-tree-* that's a kind of
> > > > C
> > > like
> > > > language so argues against using tooples like the existing gimple
> > > > -fe
> > > > branch.
> > > 
> > > The dumps contain a lot of (sometimes optional) unstructured
> > > information. For 
> > > example, they show both the result of the pass and (arbitrarily
> > > unstructured) 
> > > messages about what the pass is doing.
> > > 
> > > Wouldn't it be better to get the dumps in a more structured form
> > > (e.g.,
> > > 
> > > separating IR from debug messages) before doing this?
> > 
> > I'd say a dump modifier -il to make it dump IL only (maybe into a
> > different file) plus required global info such as types would be
> > enough.
> > 
> > > > That's interesting, as you sort of note the other option is to
> > > > just
> > > scan
> > > > the output dump for what you intend to check.  The remark idea is
> > > > interesting though, the -Wsuggest-final-{method,type} warnings
> > > > are
> > > > trying to be that, and istr something else like that.
> > > > 
> > > > > foo.c:27:10: remark: loop is not vectorizable since the
> > > > > iterator can
> > > be
> > > > > modified... [-Rvectorization]
> > > > > foo.c.35:20: ...here
> > > > > 
> > > > > or similar, where the user passed say "-Rvectorization" as a
> > > > > command
> > > > > line option to request more info on vectorization, and our test
> > > suites
> > > > > could do this.
> > > 
> > > Isn't this what -fopt-info does? 
> > > https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html
> > 
> > Yes.
> 
> One difference is that in this proposal, the output is emitted as a
> diagnostic, rather than to a file.

I don't think that's really much of a difference, I could imagine it being
useful to output diagnostics to a file rather than stdout / stderr with
something like -fwarnings-file=foo.warn.  And come to think of it that
could actually be really nice for parrallel builds so you don't have to
scroll back a ton to find the error.

> FWIW, I find those existing options to be very fiddly to use (and
> they're categorized as "GCC Developer Options").

I can believe they could use some improvement.  The point is I think
that they are trying to solve very similar or the same problem.

> > > > > As a thought-experiment, consider that as well as cc1 etc, we
> > > > > could
> > > > > have an executable for every pass.  Then you could run
> > > > > individual
> > > > > passes e.g.:
> > > > > 
> > > > >    $ run-vrp foo.gimple -o bar.gimple
> > > > >    $ run-switchconv quux.gimple -o baz.gimple
> > > > > 
> > > > > etc.   (I'm not convinced that it makes sense to split things
> > > > > up so
> > > > > much, but I find it useful for inspiration, for getting ideas
> > > > > about
> > > the
> > > > > things that we could do if we had that level of modularity,
> > > especially
> > > > > from a testing perpective).
> > > 
> > > You can have a FE that reads gimple and outputs gimple, and allows
> > > to
> > > enable 
> > > any individual optimization flags without an -O option, such as:
> > > 
> > > $ gimple -ftree-vrp foo.gimple -o bar.gimple
> > > 
> > > The driver could also learn about *.gimple files in order to invoke
> > > the
> > > gimple 
> > > front-end. This way, you can use the same option names for the
> > > gimple
> > > FE and 
> > > the rest of GCC.
> > > 
> > > Of course, ideally, the pass manager would be all modular, based on
> > > dependencies and re-configurable like 
> > > http://llvm.org/docs/CommandGuide/opt.html I wonder how far away is
> > > GCC's 
> > > middle-end from being able to do that.
> > 
> > For any kind of unit testing you need to develop some pass manager
> > support.
> 
> (nods)
> 
> > > > > > 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.
> > > > > 
> > > > > ...it sounds like you have a radically different implementation
> > > idea,
> > > > > in which the gimple frontend effectively becomes part of the C
> > > > > frontend, with some different behaviors.
> > > > 
> > > > Well, it seems like if the existing gimple-fe is basically just a
> > > parser
> > > > for a language we don't like there isn't much value in building
> > > > off
> > > of
> > > > it instead of writing something from scratch.
> > > > 
> > > > Being compatable with C probably with some builtins to do SSA
> > > > stuff
> > > > seems pretty nice.  I worry some about the work to avoid folding
> > > > and
> > > > stuff, but sharing code with the c-family languages seems good if
> > > > we
> > > > can.
> > > 
> > > Sharing code is good. Extending the C (or C++?) FE to also parse
> > > gimple-C seems 
> > > a terrible idea because how badly non-modular GCC is already. It
> > > seems
> > > better 
> > > to make gimple-C a c-family language, so it can share functions
> > > with
> > > other 
> > > C-family languages, but fork every function/data structure that
> > > requires 
> > > modification.
> > > 
> > > Moreover, such a gimple-C parser should be significantly simpler
> > > than a
> > > full 
> > > featured C parser if gimple-C is assumed to be in SSA form and all
> > > loops 
> > > lowered to goto and the syntax is only based on modern C.
> > 
> > True.  But as far as a GSoC scoped project goes I strongly suggest to
> > re-use the C FE to save you from paesing declarations and the
> > required GENERIC building.

 I think to some degree you just need to see how much of the C fe you
 need to change to get it to deal with gimple.

> FWIW I was thinking of spending a significant chunk of $DAYJOB in gcc 7
> stage 1 hacking on a gimple FE, for the purposes of unit testing of
> passes, rather that it being "just" a GSoC scoped project.

Well, we should avoid making a total mess of the C fe, but even we can
create a gimple fe with less effort than that why not? there's plenty of
other things to improve.

> > Also note my suggestion that all GIMPLE sources should be valid C as
> > well it would be unfortunate to lose the option to torture unit
> > tests.
> 
> This is possibly a silly question, but why would a custom C-like FE for
> a language that isn't quite C rule out torturing unit tests?  Can't we
> inject the gimple at the stage it was generated, and then supply
> various -O options to run various combinations of passes?
> 
> If we did it directly using the C frontend, from an implementation
> point of view, would it be something like this:
>   * the modified c frontend would build trees with lang-specific nodes
> (as before)
>   * it only accepts sufficiently "flat" trees that conform to gimple
> statements (issuing errors for e.g. nested expressions)
>   * gimple statements would then be generated directly from those flat
> trees, supporting the various stages of gimple:
>     * before CFG, 
>     * with CFG but before SSA
>     * CFG + SSA
>     so that we can unit-test all of the gimple passes including e.g.
> unit-testing the creation of CFG and conversion to SSA
>   * some kind of new builtin for phi nodes
> ?
> 
> (Though hacking up the C frontend might be a suitable way to prototype
> a dedicated gimple frontend; runs into issues of having them diverge. 
>  I don't know how much we'd want in common vs how much has to be
> different)

yeah, I imagine you'd first hack up the C fe, and then find ways to
split out shared functionality until you had two separate front ends.
Of course spliting stuff out of the C fe first to reuse sounds nicer,
but I suspect its harder because you don't really know what the consumer
looks like yet.

> (potentially we could define a subset of e.g. C99 that would be
> acceptable as gimple.  I don't know if that's helpful)

Well, it seems approachable for people who don't spend all their time on
> 
gcc which is good.

Trev

> 
> 
> Dave
> 
> > Richard.
> > 
> > > Cheers,
> > > 
> > > 	Manuel.
> > 
> > 

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

[Manuel López-Ibáñez]

On 8 March 2016 at 16:47, David Malcolm <dmalcolm@redhat.com> wrote:
>> > Isn't this what -fopt-info does?
>> > https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html
>>
>> Yes.
>
> One difference is that in this proposal, the output is emitted as a
> diagnostic, rather than to a file.

-fopt-info prints to stderr by default. I haven't used the current
version. The original version of -fopt-info was very similar to what
you described above.

> FWIW, I find those existing options to be very fiddly to use (and
> they're categorized as "GCC Developer Options").

Not sure what you mean exactly by fiddly. I think they are categorized
as "GCC Developer Options" because the main users are developers
working on GCC optimizations, and there has been little interest in
making the output consistent and user-friendly. I seem to remember
that the original proposal by Google devs was to make -fopt-info a way
for users to understand how their code was or not optimized. That
would not match your description either, because you want to use it
for unit-testing, thus it will still be a "developer" option.

>> > Of course, ideally, the pass manager would be all modular, based on
>> > dependencies and re-configurable like
>> > http://llvm.org/docs/CommandGuide/opt.html I wonder how far away is
>> > GCC's
>> > middle-end from being able to do that.
>>
>> For any kind of unit testing you need to develop some pass manager
>> support.
>
> (nods)

Which seems orthogonal to having a gimple-fe. That is, a gcc version
of the llvm opt tool would be useful even if it needed to go through
the existing FEs. It would be very useful to unit-testing specific
passes or sequences of passes. It would also be pretty
uncontroversial. And not something that a GSoC student could even
attempt, given the need to spent significant time/effort in coming up
with an overall design for the pass manager.

> This is possibly a silly question, but why would a custom C-like FE for
> a language that isn't quite C rule out torturing unit tests?  Can't we
> inject the gimple at the stage it was generated, and then supply
> various -O options to run various combinations of passes?

Indeed.

> (Though hacking up the C frontend might be a suitable way to prototype
> a dedicated gimple frontend; runs into issues of having them diverge.
>  I don't know how much we'd want in common vs how much has to be
> different)
>
> (potentially we could define a subset of e.g. C99 that would be
> acceptable as gimple.  I don't know if that's helpful)

A first step would be to dump something that is parseable as a subset
of C. I don't think we are nowhere near that. And that would still not
be enough, since I don't think we dump all details of gimple. The C FE
also would need to be able to parse as gimple things like look like C
but are significantly different (like Fortran explicit parentheses).

Adding stuff to the C FE might seem the fast path forward, but we will
end up with a gimple-fe as complex as the whole C FE plus the extra
bits for parsing all the non-C stuff. That seems very undesirable in
the long run. To be clear, what I would propose if a C-like
representation is desired is "cp -a c cgimple", and start deleting all
the things that are not needed by cgimple and adding all the extra
stuff needed.

Since the goal seems to be to be able to dump/reload some kind of IR
rather than a textual representation of GIMPLE tuples, why not
dump/load LLVM IR? The GIMPLE=>LLVM is already implemented as a GPL
plugin in dragonegg.
http://llvm.org/devmtg/2009-10/Sands_LLVMGCCPlugin.pdf
It is not a suggestion, but I would like to know what you think about
the advantages/disadvantages.

Cheers,

Manuel.

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

[Manuel López-Ibáñez]

On 8 March 2016 at 21:00, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote:
> Since the goal seems to be to be able to dump/reload some kind of IR
> rather than a textual representation of GIMPLE tuples, why not
> dump/load LLVM IR? The GIMPLE=>LLVM is already implemented as a GPL
> plugin in dragonegg.
> http://llvm.org/devmtg/2009-10/Sands_LLVMGCCPlugin.pdf
> It is not a suggestion, but I would like to know what you think about
> the advantages/disadvantages.

One of the advantages would be to make available to GCC all the tools
developed around LLVM IR, such as
http://blog.regehr.org/archives/1170
Also, it will bring GCC's middle-end closer to what people in academia
are actually using.

Cheers,

Manuel.

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

[David Malcolm]

On Tue, 2016-03-08 at 21:00 +0000, Manuel López-Ibáñez wrote:
> On 8 March 2016 at 16:47, David Malcolm <dmalcolm@redhat.com> wrote:
> > > > Isn't this what -fopt-info does?
> > > > https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html
> > > 
> > > Yes.
> > 
> > One difference is that in this proposal, the output is emitted as a
> > diagnostic, rather than to a file.
> 
> -fopt-info prints to stderr by default. I haven't used the current
> version. The original version of -fopt-info was very similar to what
> you described above.
> 
> > FWIW, I find those existing options to be very fiddly to use (and
> > they're categorized as "GCC Developer Options").
> 
> Not sure what you mean exactly by fiddly. I think they are
> categorized
> as "GCC Developer Options" because the main users are developers
> working on GCC optimizations, and there has been little interest in
> making the output consistent and user-friendly. I seem to remember
> that the original proposal by Google devs was to make -fopt-info a
> way
> for users to understand how their code was or not optimized. That
> would not match your description either, because you want to use it
> for unit-testing, thus it will still be a "developer" option.
> 
> > > > Of course, ideally, the pass manager would be all modular,
> > > > based on
> > > > dependencies and re-configurable like
> > > > http://llvm.org/docs/CommandGuide/opt.html I wonder how far
> > > > away is
> > > > GCC's
> > > > middle-end from being able to do that.
> > > 
> > > For any kind of unit testing you need to develop some pass
> > > manager
> > > support.
> > 
> > (nods)
> 
> Which seems orthogonal to having a gimple-fe. That is, a gcc version
> of the llvm opt tool would be useful even if it needed to go through
> the existing FEs. It would be very useful to unit-testing specific
> passes or sequences of passes. It would also be pretty
> uncontroversial. And not something that a GSoC student could even
> attempt, given the need to spent significant time/effort in coming up
> with an overall design for the pass manager.
> 
> > This is possibly a silly question, but why would a custom C-like FE
> > for
> > a language that isn't quite C rule out torturing unit tests?  Can't
> > we
> > inject the gimple at the stage it was generated, and then supply
> > various -O options to run various combinations of passes?
> 
> Indeed.
> 
> > (Though hacking up the C frontend might be a suitable way to
> > prototype
> > a dedicated gimple frontend; runs into issues of having them
> > diverge.
> >  I don't know how much we'd want in common vs how much has to be
> > different)
> > 
> > (potentially we could define a subset of e.g. C99 that would be
> > acceptable as gimple.  I don't know if that's helpful)
> 
> A first step would be to dump something that is parseable as a subset
> of C. I don't think we are nowhere near that. And that would still
> not
> be enough, since I don't think we dump all details of gimple. The C
> FE
> also would need to be able to parse as gimple things like look like C
> but are significantly different (like Fortran explicit parentheses).
> 
> Adding stuff to the C FE might seem the fast path forward, but we
> will
> end up with a gimple-fe as complex as the whole C FE plus the extra
> bits for parsing all the non-C stuff. That seems very undesirable in
> the long run. To be clear, what I would propose if a C-like
> representation is desired is "cp -a c cgimple", and start deleting
> all
> the things that are not needed by cgimple and adding all the extra
> stuff needed.
> 
> Since the goal seems to be to be able to dump/reload some kind of IR
> rather than a textual representation of GIMPLE tuples, why not
> dump/load LLVM IR? The GIMPLE=>LLVM is already implemented as a GPL
> plugin in dragonegg.
> http://llvm.org/devmtg/2009-10/Sands_LLVMGCCPlugin.pdf
> It is not a suggestion, but I would like to know what you think about
> the advantages/disadvantages.

My goal for unit-testing passes is to be able to dump/reload the GIMPLE
IR in a form that's:
  (A) readable by both humans and programs, and
  (B) editable by humans
  (C) roundtrippable for some subset of the IR
  (D) can support the input for every gimple pass (pre-CFG, CFG-before
-SSA, CFG-with-SSA, with/without lowered switches etc)
  (E) can support the output of every gimple pass, apart from the final
expansion to RTL.

AIUI, Richard would also like:
  (F) the form to be parsable as C
(presumably some subset)

LLVM IR is likely similar to GIMPLE IR, but AFAIK, LLVM IR requires
SSA, which would seem to preclude using it (goals (D) and (E) above). 
 Also, there may be other things we'd want to express in GIMPLE that
might not be directly expressible in LLVM IR (Richard alluded to this
earlier in this thread: the on-the-side data: range info, points-to
info, etc).   Though I suspect converters may be feasible for some
common subset of SSA IR.

Regarding goal (F) above, AFAIK, LLVM IR has a texual assembly form and
a bitcode form; does LLVM IR have a subset-of-C form?

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

[Diego Novillo]

On Tue, Mar 8, 2016 at 4:59 PM, David Malcolm <dmalcolm@redhat.com> wrote:

> My goal for unit-testing passes is to be able to dump/reload the GIMPLE
> IR in a form that's:
>   (A) readable by both humans and programs, and
>   (B) editable by humans
>   (C) roundtrippable for some subset of the IR
>   (D) can support the input for every gimple pass (pre-CFG, CFG-before
> -SSA, CFG-with-SSA, with/without lowered switches etc)
>   (E) can support the output of every gimple pass, apart from the final
> expansion to RTL.
>
> AIUI, Richard would also like:
>   (F) the form to be parsable as C
> (presumably some subset)
>
> LLVM IR is likely similar to GIMPLE IR, but AFAIK, LLVM IR requires
> SSA, which would seem to preclude using it (goals (D) and (E) above).

LLVM IR is an SSA IR, yes.  It also has two different representations,
a text-based one parseable with its front end, and a binary one
(bitcode) which is more efficient for purposes of LTO and such
(similar to the GIMPLE bytecode lto front end).

LLVM IR is actually lower in the IR abstraction spectrum.  It's closer
to RTL than it is to GIMPLE.  For instance, its type system is very
similar to RTL: words, pointers and offsets.  A few machine features
creep in, but not many.  Things like function calls look very much
like a C function call.


>  Also, there may be other things we'd want to express in GIMPLE that
> might not be directly expressible in LLVM IR (Richard alluded to this
> earlier in this thread: the on-the-side data: range info, points-to
> info, etc).   Though I suspect converters may be feasible for some
> common subset of SSA IR.
>
> Regarding goal (F) above, AFAIK, LLVM IR has a texual assembly form and
> a bitcode form; does LLVM IR have a subset-of-C form?

Well, in the sense that it kinda looks like a very low level version
of C.  For instance,

int sum(int y, int x) { return x + y; }

becomes:

define i32 @sum(i32 %y, i32 %x) #0 {
entry:
  %y.addr = alloca i32, align 4
  %x.addr = alloca i32, align 4
  store i32 %y, i32* %y.addr, align 4
  store i32 %x, i32* %x.addr, align 4
  %0 = load i32, i32* %x.addr, align 4
  %1 = load i32, i32* %y.addr, align 4
  %add = add nsw i32 %0, %1
  ret i32 %add
}

Notice all the word operations and the SSA nature of the IL itself.


I'm hardly in a position to offer guidance here, but I'm not sure that
overloading the gimple FE on the c-family FE is desirable long term.
The two parsers are going to invariably differ in what they want to
accept, error messages, etc.  For modularity purposes, having a
separate module dealing with GIMPLE itself might be better than
piggybacking functionality on the C FE.

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.



Diego.

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

[Jeff Law]

On 03/08/2016 02:59 PM, David Malcolm wrote:
> On Tue, 2016-03-08 at 21:00 +0000, Manuel López-Ibáñez wrote:
>> On 8 March 2016 at 16:47, David Malcolm <dmalcolm@redhat.com> wrote:
>>>>> Isn't this what -fopt-info does?
>>>>> https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html
>>>>
>>>> Yes.
>>>
>>> One difference is that in this proposal, the output is emitted as a
>>> diagnostic, rather than to a file.
>>
>> -fopt-info prints to stderr by default. I haven't used the current
>> version. The original version of -fopt-info was very similar to what
>> you described above.
>>
>>> FWIW, I find those existing options to be very fiddly to use (and
>>> they're categorized as "GCC Developer Options").
>>
>> Not sure what you mean exactly by fiddly. I think they are
>> categorized
>> as "GCC Developer Options" because the main users are developers
>> working on GCC optimizations, and there has been little interest in
>> making the output consistent and user-friendly. I seem to remember
>> that the original proposal by Google devs was to make -fopt-info a
>> way
>> for users to understand how their code was or not optimized. That
>> would not match your description either, because you want to use it
>> for unit-testing, thus it will still be a "developer" option.
>>
>>>>> Of course, ideally, the pass manager would be all modular,
>>>>> based on
>>>>> dependencies and re-configurable like
>>>>> http://llvm.org/docs/CommandGuide/opt.html I wonder how far
>>>>> away is
>>>>> GCC's
>>>>> middle-end from being able to do that.
>>>>
>>>> For any kind of unit testing you need to develop some pass
>>>> manager
>>>> support.
>>>
>>> (nods)
>>
>> Which seems orthogonal to having a gimple-fe. That is, a gcc version
>> of the llvm opt tool would be useful even if it needed to go through
>> the existing FEs. It would be very useful to unit-testing specific
>> passes or sequences of passes. It would also be pretty
>> uncontroversial. And not something that a GSoC student could even
>> attempt, given the need to spent significant time/effort in coming up
>> with an overall design for the pass manager.
>>
>>> This is possibly a silly question, but why would a custom C-like FE
>>> for
>>> a language that isn't quite C rule out torturing unit tests?  Can't
>>> we
>>> inject the gimple at the stage it was generated, and then supply
>>> various -O options to run various combinations of passes?
>>
>> Indeed.
>>
>>> (Though hacking up the C frontend might be a suitable way to
>>> prototype
>>> a dedicated gimple frontend; runs into issues of having them
>>> diverge.
>>>   I don't know how much we'd want in common vs how much has to be
>>> different)
>>>
>>> (potentially we could define a subset of e.g. C99 that would be
>>> acceptable as gimple.  I don't know if that's helpful)
>>
>> A first step would be to dump something that is parseable as a subset
>> of C. I don't think we are nowhere near that. And that would still
>> not
>> be enough, since I don't think we dump all details of gimple. The C
>> FE
>> also would need to be able to parse as gimple things like look like C
>> but are significantly different (like Fortran explicit parentheses).
>>
>> Adding stuff to the C FE might seem the fast path forward, but we
>> will
>> end up with a gimple-fe as complex as the whole C FE plus the extra
>> bits for parsing all the non-C stuff. That seems very undesirable in
>> the long run. To be clear, what I would propose if a C-like
>> representation is desired is "cp -a c cgimple", and start deleting
>> all
>> the things that are not needed by cgimple and adding all the extra
>> stuff needed.
>>
>> Since the goal seems to be to be able to dump/reload some kind of IR
>> rather than a textual representation of GIMPLE tuples, why not
>> dump/load LLVM IR? The GIMPLE=>LLVM is already implemented as a GPL
>> plugin in dragonegg.
>> http://llvm.org/devmtg/2009-10/Sands_LLVMGCCPlugin.pdf
>> It is not a suggestion, but I would like to know what you think about
>> the advantages/disadvantages.
>
> My goal for unit-testing passes is to be able to dump/reload the GIMPLE
> IR in a form that's:
>    (A) readable by both humans and programs, and
>    (B) editable by humans
>    (C) roundtrippable for some subset of the IR
>    (D) can support the input for every gimple pass (pre-CFG, CFG-before
> -SSA, CFG-with-SSA, with/without lowered switches etc)
>    (E) can support the output of every gimple pass, apart from the final
> expansion to RTL.
I'll come back to my assertion that this really should be 
reading/writing a textual LTO.

By definition, everything we need is currently streamed in/out by the 
LTO bits.  What's needed is (in essence) is to virtualize that interface 
to have textual forms.

Jeff

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

[Trevor Saunders]

On Tue, Mar 08, 2016 at 05:12:56PM -0500, Diego Novillo wrote:
> On Tue, Mar 8, 2016 at 4:59 PM, David Malcolm <dmalcolm@redhat.com> wrote:
> 
> > My goal for unit-testing passes is to be able to dump/reload the GIMPLE
> > IR in a form that's:
> >   (A) readable by both humans and programs, and
> >   (B) editable by humans
> >   (C) roundtrippable for some subset of the IR
> >   (D) can support the input for every gimple pass (pre-CFG, CFG-before
> > -SSA, CFG-with-SSA, with/without lowered switches etc)
> >   (E) can support the output of every gimple pass, apart from the final
> > expansion to RTL.
> >
> > AIUI, Richard would also like:
> >   (F) the form to be parsable as C
> > (presumably some subset)
> >
> > LLVM IR is likely similar to GIMPLE IR, but AFAIK, LLVM IR requires
> > SSA, which would seem to preclude using it (goals (D) and (E) above).
> 
> LLVM IR is an SSA IR, yes.  It also has two different representations,
> a text-based one parseable with its front end, and a binary one
> (bitcode) which is more efficient for purposes of LTO and such
> (similar to the GIMPLE bytecode lto front end).
> 
> LLVM IR is actually lower in the IR abstraction spectrum.  It's closer
> to RTL than it is to GIMPLE.  For instance, its type system is very
> similar to RTL: words, pointers and offsets.  A few machine features
> creep in, but not many.  Things like function calls look very much
> like a C function call.
> 
> 
> >  Also, there may be other things we'd want to express in GIMPLE that
> > might not be directly expressible in LLVM IR (Richard alluded to this
> > earlier in this thread: the on-the-side data: range info, points-to
> > info, etc).   Though I suspect converters may be feasible for some
> > common subset of SSA IR.
> >
> > Regarding goal (F) above, AFAIK, LLVM IR has a texual assembly form and
> > a bitcode form; does LLVM IR have a subset-of-C form?
> 
> Well, in the sense that it kinda looks like a very low level version
> of C.  For instance,
> 
> int sum(int y, int x) { return x + y; }
> 
> becomes:
> 
> define i32 @sum(i32 %y, i32 %x) #0 {
> entry:
>   %y.addr = alloca i32, align 4
>   %x.addr = alloca i32, align 4
>   store i32 %y, i32* %y.addr, align 4
>   store i32 %x, i32* %x.addr, align 4
>   %0 = load i32, i32* %x.addr, align 4
>   %1 = load i32, i32* %y.addr, align 4
>   %add = add nsw i32 %0, %1
>   ret i32 %add
> }
> 
> Notice all the word operations and the SSA nature of the IL itself.
> 
> 
> I'm hardly in a position to offer guidance here, but I'm not sure that
> overloading the gimple FE on the c-family FE is desirable long term.

I'm kind of on the fence there.

> The two parsers are going to invariably differ in what they want to
> accept, error messages, etc.  For modularity purposes, having a

I'm not sure they really will so far as types are concerned.  As far as
expressions and statements go they probably should be different.

> separate module dealing with GIMPLE itself might be better than
> piggybacking functionality on the C FE.

My concern is that writing a separate gimple parser will require
basically a copy of all the code to parse decls and types, but maybe
that isn't that much?

> 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).

Trev

> 
> 
> 
> Diego.

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

[Andrew MacLeod]

On 03/07/2016 11:33 AM, David Malcolm wrote:
>>
>>
>>
>>
>> So for testing specific passes, I'd much rather have an input format
>> for testing individual passes that:
>>    * can be easily generated by GCC from real test cases
>>    * ability to turn into unit tests, which implies:
>>      * human-readable and editable
>>    * compatibility and stability: can load gcc 7 test cases into gcc 8;
>> have e.g. gcc 6 generate test cases
>>    * roundtrippable: can load the format, then save out the IR, and get
>> the same file, for at least some subset of the format (consider e.g.
>> location data: explicit location data can be roundtripped, implicit
>> location data not so much).
>>
>> ...which suggests that we'd want to use gimple dumps as the input
>> format to a test framework - which leads naturally to the idea of a
>> gimple frontend.


We already read and write gimple IL in LTO, we just do it in binary 
form.  I think the kind of effort you are talking about here is best 
placed in attaching a gimple parser to LTO, thus giving LTO the ability 
to read and write textual gimple as well as the current binary form.     
The current dump format could in theory be a starting point, but its 
clearly missing hunks of stuff.  there is probably a better representation.

LTO already knows all the bits required to reconstruct gimple. The 
definition of the textual representation can make intelligent choices 
about defaults so that you don't have to specify every single bit in the 
textual form that the binary form requires.  ThIs seems far easier to me 
than starting with the incomplete form that the current dumps generate 
and trying to discover what other bits need to be added to properly 
reconstruct the IL.  I think its hard to get a lot of the subtle things 
right.    I also think the scope of defining and reading/writing should 
be relatively manageable.  We can optimize the details once its working.

It would also be very useful then  to have LTO enhanced so that it can 
read and write before or after any pass...  Then we can unit test any 
pass by injecting the IL immediately before the pass..  No jumping 
through any hoops to make sure the pass you care about sees the exact IL 
you want..   That is also a good proof that the LTO form (both binary 
and text) does fully represent gimple.  We can also use this output as 
our debugging dumps and archive the current dumper.

As gimple changes and evolves the result is only one place to worry 
about for reading and writing...  and as we progress (slowly) towards 
uncoupling the middle/backend from the front ends, we'd have a single 
well defined "front end" for gimple that accepts binary or text.

Andrew

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

[Richard Biener]

On Wed, Mar 9, 2016 at 3:27 PM, Andrew MacLeod <amacleod@redhat.com> wrote:
> On 03/07/2016 11:33 AM, David Malcolm wrote:
>>>
>>>
>>>
>>>
>>>
>>> So for testing specific passes, I'd much rather have an input format
>>> for testing individual passes that:
>>>    * can be easily generated by GCC from real test cases
>>>    * ability to turn into unit tests, which implies:
>>>      * human-readable and editable
>>>    * compatibility and stability: can load gcc 7 test cases into gcc 8;
>>> have e.g. gcc 6 generate test cases
>>>    * roundtrippable: can load the format, then save out the IR, and get
>>> the same file, for at least some subset of the format (consider e.g.
>>> location data: explicit location data can be roundtripped, implicit
>>> location data not so much).
>>>
>>> ...which suggests that we'd want to use gimple dumps as the input
>>> format to a test framework - which leads naturally to the idea of a
>>> gimple frontend.
>
>
>
> We already read and write gimple IL in LTO, we just do it in binary form.  I
> think the kind of effort you are talking about here is best placed in
> attaching a gimple parser to LTO, thus giving LTO the ability to read and
> write textual gimple as well as the current binary form.     The current
> dump format could in theory be a starting point, but its clearly missing
> hunks of stuff.  there is probably a better representation.
>
> LTO already knows all the bits required to reconstruct gimple. The
> definition of the textual representation can make intelligent choices about
> defaults so that you don't have to specify every single bit in the textual
> form that the binary form requires.  ThIs seems far easier to me than
> starting with the incomplete form that the current dumps generate and trying
> to discover what other bits need to be added to properly reconstruct the IL.
> I think its hard to get a lot of the subtle things right.    I also think
> the scope of defining and reading/writing should be relatively manageable.
> We can optimize the details once its working.
>
> It would also be very useful then  to have LTO enhanced so that it can read
> and write before or after any pass...  Then we can unit test any pass by
> injecting the IL immediately before the pass..  No jumping through any hoops
> to make sure the pass you care about sees the exact IL you want..   That is
> also a good proof that the LTO form (both binary and text) does fully
> represent gimple.  We can also use this output as our debugging dumps and
> archive the current dumper.
>
> As gimple changes and evolves the result is only one place to worry about
> for reading and writing...  and as we progress (slowly) towards uncoupling
> the middle/backend from the front ends, we'd have a single well defined
> "front end" for gimple that accepts binary or text.

So I chose to reply to this one (and will refrain from replying to other but try
to address comments there).

First, while the LTO approach works it's quite overkill in the details
it "dumps"
and thus it's too closely tied to our internal bits which means testcases will
bitrot too quickly for the number one goal of having human
maintainable testcases.

It's nice if there's going to be somebody spending quite some of his
work-time towards
unit-testing (hope not specifically "the GIMPLE frontend").

In my view the C frontend already can target most of the middle-end features and
for those it can't it should be straight-forward to add GNU extensions
for.  A critical
piece is of course SSA here, specifically PHIs.  I think a reasonable way to
express those in C are to use labels:

int i;
if (...)
 {
L1:
   i_1 = 2;
 }
else
 {
L2:;
 }
i_3 = __PHI (L1:i_1, L2:i);

so the testcases would be valid GNU C (not C).  What would be missing for
unit-testing would be some "raw" mode to avoid having the C FE fold things
or apply type promotions (so you can actually write a signed short addition).

As of restricting statements to GIMPLE I think that's not necessary - I'd simply
run the GENERIC from the FE through the gimplifier (I have patches that deal
with SSA pre into-SSA just fine, at least for non-PHIs, and if all the
__PHI above
could be just an internal function pre "real" SSA).

Note that I don't think we should restrict ourselves by connecting what LTO does
with what the requirements for unit testing are.  The convenient bit of
extending the C FE here is that dumping a function body in the required form
is going to be easy and that you can have a testcase harness in plain C while
feeding in a unit-test function as "GNU C GIMPLE" (or how you'll call it).  Say,

extern void abort (void);

int x;

int __attribute__((GIMPLE)) foo ()
{
  int _1;
  _1 = x;
  return _1;
}

int main()
{
  if (foo () != 1)
   abort ();
  return 0;
}

and the above would extend to __attribute__((RTL)) if anybody wants to
introduce that.
Give 'GIMPLE' an argument like __attribute__((GIMPLE("tree-pre"))) to
specify the
place to inject the function [you still have to feed it to the cgraph
from the beginning
of course, but the pass manager would skip anything before tree-pre for example
but still eventually compute IL side-data via required PROP_s]


Yes, a textual form for LTO data would be nice (or rather a self-descriptive LTO
data format so you can have external tools dump it).  But I don't think using
the LTO dumper will work for unit testing.


About using the LLVM IR - similar issue I think, plus it is probably
too far away
from GCC so that what we'll end up will only look like LLVM IR but not actually
be LLVM IR.


I think with sticking to C and re-using (parts of) the frontend the path to
first "success" can be much shorter which I think is important for the
project to not bitrot in an unusable state like the last attempt.  Of
course while
I can spend some cycles mentoring a GSoC student I won't spend a
significant fraction of my work time on this project.


Richard.

> Andrew
>

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

[Diego Novillo]

On Wed, Mar 9, 2016 at 10:47 AM, Richard Biener
<richard.guenther@gmail.com> wrote:

> About using the LLVM IR - similar issue I think, plus it is probably
> too far away
> from GCC so that what we'll end up will only look like LLVM IR but not actually
> be LLVM IR.

I don't think this is feasible at all, actually.  As I said in my
message, LLVM IR and GIMPLE are fairly different in terms of
abstraction.

The main goal is providing a text-based representation for GIMPLE that
can be used as input into any arbitrary stage of the optimizer.  This
also implies other modularization efforts that allow this.

Whether or not GIMPLE looks like C, or this is done piggybacking the C
FE, is a different issue.  I think the first issue to solve is
defining GIMPLE as a full, compilable language with well formed
execution and data semantics.


Diego.

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

[Richard Biener]

On Wed, Mar 9, 2016 at 5:07 PM, Diego Novillo <dnovillo@google.com> wrote:
> On Wed, Mar 9, 2016 at 10:47 AM, Richard Biener
> <richard.guenther@gmail.com> wrote:
>
>> About using the LLVM IR - similar issue I think, plus it is probably
>> too far away
>> from GCC so that what we'll end up will only look like LLVM IR but not actually
>> be LLVM IR.
>
> I don't think this is feasible at all, actually.  As I said in my
> message, LLVM IR and GIMPLE are fairly different in terms of
> abstraction.
>
> The main goal is providing a text-based representation for GIMPLE that
> can be used as input into any arbitrary stage of the optimizer.  This
> also implies other modularization efforts that allow this.
>
> Whether or not GIMPLE looks like C, or this is done piggybacking the C
> FE, is a different issue.  I think the first issue to solve is
> defining GIMPLE as a full, compilable language with well formed
> execution and data semantics.

I don't think that's necessary.  GIMPLE is an implementation detail and it
should remain that.  For unit testing it's only required to be able to input
sth resembling GIMPLE close enough.  All is necessary is to define
execution and data semantics of the C extensions we need to get "close enough".
After all GIMPLEs execution and data semantics are basically Cs (with some
extras not covered by C).

Richard.

>
> Diego.

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

[Andrew MacLeod]

On 03/09/2016 10:47 AM, Richard Biener wrote:
> On Wed, Mar 9, 2016 at 3:27 PM, Andrew MacLeod <amacleod@redhat.com> wrote:
>> On 03/07/2016 11:33 AM, David Malcolm wrote:
>>>>
>>>>
>>>>
>>>>
>>>> So for testing specific passes, I'd much rather have an input format
>>>> for testing individual passes that:
>>>>     * can be easily generated by GCC from real test cases
>>>>     * ability to turn into unit tests, which implies:
>>>>       * human-readable and editable
>>>>     * compatibility and stability: can load gcc 7 test cases into gcc 8;
>>>> have e.g. gcc 6 generate test cases
>>>>     * roundtrippable: can load the format, then save out the IR, and get
>>>> the same file, for at least some subset of the format (consider e.g.
>>>> location data: explicit location data can be roundtripped, implicit
>>>> location data not so much).
>>>>
>>>> ...which suggests that we'd want to use gimple dumps as the input
>>>> format to a test framework - which leads naturally to the idea of a
>>>> gimple frontend.
>>
>>
>> We already read and write gimple IL in LTO, we just do it in binary form.  I
>> think the kind of effort you are talking about here is best placed in
>> attaching a gimple parser to LTO, thus giving LTO the ability to read and
>> write textual gimple as well as the current binary form.     The current
>> dump format could in theory be a starting point, but its clearly missing
>> hunks of stuff.  there is probably a better representation.
>>
>> LTO already knows all the bits required to reconstruct gimple. The
>> definition of the textual representation can make intelligent choices about
>> defaults so that you don't have to specify every single bit in the textual
>> form that the binary form requires.  ThIs seems far easier to me than
>> starting with the incomplete form that the current dumps generate and trying
>> to discover what other bits need to be added to properly reconstruct the IL.
>> I think its hard to get a lot of the subtle things right.    I also think
>> the scope of defining and reading/writing should be relatively manageable.
>> We can optimize the details once its working.
>>
>> It would also be very useful then  to have LTO enhanced so that it can read
>> and write before or after any pass...  Then we can unit test any pass by
>> injecting the IL immediately before the pass..  No jumping through any hoops
>> to make sure the pass you care about sees the exact IL you want..   That is
>> also a good proof that the LTO form (both binary and text) does fully
>> represent gimple.  We can also use this output as our debugging dumps and
>> archive the current dumper.
>>
>> As gimple changes and evolves the result is only one place to worry about
>> for reading and writing...  and as we progress (slowly) towards uncoupling
>> the middle/backend from the front ends, we'd have a single well defined
>> "front end" for gimple that accepts binary or text.
> So I chose to reply to this one (and will refrain from replying to other but try
> to address comments there).
>
> First, while the LTO approach works it's quite overkill in the details
> it "dumps"
> and thus it's too closely tied to our internal bits which means testcases will
> bitrot too quickly for the number one goal of having human
> maintainable testcases.
>

The binary form is clearly tied to a lot of implementation bits, but I 
would think a lot of those bits have a reasonable default value that 
wouldn't have to be explicitly expressed in textual form, but could be 
if so desired via attributes, tags, new keywords,  or whatever.

  The current dumps are C-like and could work as a decent starting point 
for textual gimple input/output.   From the LTO vantage point, you can 
see all the other bits which might need to be expressed, and can get to 
them later.   That is "merely" the follow on hard work of flushing out 
the details :-)

I'd just hate to see a lot of work go into it and have it made 
completely redundant in a  few years by the presence of a new lto 
reader/writer than can do the same job.  Of course that's still blue-sky 
stuff and could never happen.

No matter what approach is taken, it would be good to keep in mind the 
possibility of enhancing it to be the LTO text reader so that decisions 
aren't made which make that impractical..    I don't think its on my hit 
list for a while yet... but it would be really  nice to be able to 
leverage any work that is done in this direction.  It would be ideal to 
be able to simply add enhancements to whatever we have to provide the 
rest of what LTO requires to be a complete reader/writer.

Andrew

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

[Manuel López-Ibáñez]

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?
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.

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

[Eric Botcazou]

> 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.

No, it doesn't, only to GENERIC, i.e. everything is lowered in GIMPLE and as 
far as I know there are no Ada-specific constructs in GIMPLE, so you can take 
Ada completely out of the picture here.

-- 
Eric Botcazou

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

[Trevor Saunders]

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.

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

[Prasad Ghangal]

I would like to clear some doubts regarding project.

Basic goals in the project will be (please correct me if I am wrong):
  1. Developing FE for C like gimple IR - basically by extending or
modifying C FE (I can see most are in favour of not including gimple-C
into c-family languages)
  2. And adding a way to pass gimple into specific pass.
(I am not sure what Dave suggested i.e. to improve diagnostic would be
in the scope. Please correct me if I missed any)

This will be definitely very helpful for unit testing.

I have following queries:
  1. Upto what level we want C like structure in gimple (we will have
to modify CFG, PHI nodes accordingly)
  2. Do we have to develop new grammar for gimple-C ?



-- 
Thanks and Regards,
Prasad Ghangal

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

[Richard Biener]

On Wed, Mar 9, 2016 at 8:45 PM, Manuel López-Ibáñez
<lopezibanez@gmail.com> 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?
> 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.

Thanks,
Richard.

> Cheers,
>
> Manuel.

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

[Richard Biener]

On Thu, Mar 10, 2016 at 11:46 AM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Wed, Mar 9, 2016 at 8:45 PM, Manuel López-Ibáñez
> <lopezibanez@gmail.com> 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?
>> 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.

[PATCH] Hack to make gimple dump parseable as C (was Re: [gimplefe] [gsoc16] Gimple Front End Project)

[David Malcolm]

[-- Attachment #1: Type: text/plain, Size: 7864 bytes --]

On Thu, 2016-03-10 at 11:50 +0100, Richard Biener wrote:
> On Thu, Mar 10, 2016 at 11:46 AM, Richard Biener
> <richard.guenther@gmail.com> wrote:
> > On Wed, Mar 9, 2016 at 8:45 PM, Manuel López-Ibáñez
> > <lopezibanez@gmail.com> 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?
> > > 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.

I'll try to summarize the implementation approaches suggested so far:

(1) use the existing "gimple-front-end" branch
  (1.1) tuple-based format
  (1.2) rework/rewrite it to use a C-like format

(2) use the C frontend, with a new -fgimple option

(3) use/rework the LTO streamer code, with a textual format.


For both (1) and (2) we'd need input data.  We could:
 (A) adapt the existing dumper to be more amenable to loading as C, or
 (B) write a new dumper

I've been doing some rough prototyping work of (A).  (I've also been
doing some prototyping of (3), hacking up the LTO streamer; I'll post
that separately).

Attached is a crude patch that hacks up the existing gimple dumping
enough for it to be *mostly* parsable as C, along with a test file
(test-loop.c), and the sample output (test-loop.c.018t.ssa).

Generating the dumpfile:
  $ ./xgcc -B. -c ../../src/test-loop.c -fdump-tree-ssa

Reading it:
  $ ./xgcc -B. -xc test-loop.c.018t.ssa -fgimple

The "-fgimple" does nothing yet.  The existing C FE parses the result,
mostly: the dumps don't contain type information, and the parser can't
handle phi nodes, so we get:

test-loop.c.018t.ssa: In function ‘test_1’:
test-loop.c.018t.ssa:28:8: warning: implicit declaration of function
‘__PHI’ [-Wimplicit-function-declaration]
   _1 = __PHI (/* bb_3:*/_5, /* bb_4:*/_6);
        ^~~~~
test-loop.c.018t.ssa: At top level:
test-loop.c.018t.ssa:39:16: warning: ‘struct foo’ declared inside
parameter list will not be visible outside of this definition or
declaration
 test_2 (struct foo * lhs, struct foo * rhs)
                ^~~
test-loop.c.018t.ssa: In function ‘test_2’:
test-loop.c.018t.ssa:67:13: error: dereferencing pointer to incomplete
type ‘struct foo’
   _6 = lhs_5->count;
             ^~

I stripped off the "(D)" suffix from the default defs e.g.:

     struct foo * lhs_5(D);
            ^~~
so there isn't a way to see if SSA_NAME_IS_DEFAULT_DEF (node) is set on
an SSA_NAME in this representation (perhaps we could synthesize an
assignment at the decl of the SSA_NAME, so it becomes e.g.:

     struct foo * lhs_5 = lhs;

Also, this is throwing away parts of the IR (e.g. loop information), in
the hope that it can be constructed faithfully on load.

But with all these caveats it does (mostly) parse as C.

I haven't yet attempted to directly make gimple from this when -fgimple
is set; does that seem like a worthwhile experiment?

Hope this is constructive
Dave

[-- Attachment #2: hack-up-the-gimple-dumper.patch --]
[-- Type: text/x-patch, Size: 8842 bytes --]

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 7c5f6c7..ac0173d 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1227,6 +1227,10 @@ ffreestanding
 C ObjC C++ ObjC++
 Do not assume that standard C libraries and \"main\" exist.
 
+fgimple
+C Var(flag_gimple, 0)
+Parse as GNU GIMPLE
+
 fgnu-keywords
 C++ ObjC++ Var(flag_no_gnu_keywords, 0)
 Recognize GNU-defined keywords.
diff --git a/gcc/gimple-pretty-print.c b/gcc/gimple-pretty-print.c
index e27214f..7d90072 100644
--- a/gcc/gimple-pretty-print.c
+++ b/gcc/gimple-pretty-print.c
@@ -864,6 +864,9 @@ static void
 dump_gimple_label (pretty_printer *buffer, glabel *gs, int spc, int flags)
 {
   tree label = gimple_label_label (gs);
+#if 1
+  pp_printf (buffer, "label_%i:", LABEL_DECL_UID (label));
+#else
   if (flags & TDF_RAW)
       dump_gimple_fmt (buffer, spc, flags, "%G <%T>", gs, label);
   else
@@ -875,6 +878,7 @@ dump_gimple_label (pretty_printer *buffer, glabel *gs, int spc, int flags)
     pp_string (buffer, " [non-local]");
   if ((flags & TDF_EH) && EH_LANDING_PAD_NR (label))
     pp_printf (buffer, " [LP %d]", EH_LANDING_PAD_NR (label));
+#endif
 }
 
 /* Dump a GIMPLE_GOTO tuple on the pretty_printer BUFFER, SPC
@@ -1933,6 +1937,23 @@ dump_gimple_phi (pretty_printer *buffer, gphi *phi, int spc, bool comment,
   if (flags & TDF_ALIAS)
     dump_ssaname_info (buffer, lhs, spc);
 
+#if 1
+  dump_generic_node (buffer, lhs, spc, flags, false);
+  pp_string (buffer, " = __PHI (");
+  for (i = 0; i < gimple_phi_num_args (phi); i++)
+    {
+      if ((flags & TDF_LINENO) && gimple_phi_arg_has_location (phi, i))
+	dump_location (buffer, gimple_phi_arg_location (phi, i));
+      pp_string (buffer, "/* bb_");
+      pp_decimal_int (buffer, gimple_phi_arg_edge (phi, i)->src->index);
+      pp_string (buffer, ":*/");
+      dump_generic_node (buffer, gimple_phi_arg_def (phi, i), spc, flags,
+			 false);
+      if (i < gimple_phi_num_args (phi) - 1)
+	pp_string (buffer, ", ");
+    }
+  pp_string (buffer, ");");
+#else
   if (comment)
     pp_string (buffer, "# ");
 
@@ -1957,6 +1978,7 @@ dump_gimple_phi (pretty_printer *buffer, gphi *phi, int spc, bool comment,
 	pp_string (buffer, ", ");
     }
   pp_greater (buffer);
+#endif
 }
 
 
@@ -2402,11 +2424,7 @@ dump_gimple_bb_header (FILE *outf, basic_block bb, int indent, int flags)
 	}
     }
   else
-    {
-      gimple *stmt = first_stmt (bb);
-      if (!stmt || gimple_code (stmt) != GIMPLE_LABEL)
-	fprintf (outf, "%*s<bb %d>:\n", indent, "", bb->index);
-    }
+    fprintf (outf, "%*sbb_%d:\n", indent, "", bb->index);
 }
 
 
@@ -2451,24 +2469,9 @@ dump_phi_nodes (pretty_printer *buffer, basic_block bb, int indent, int flags)
 static void
 pp_cfg_jump (pretty_printer *buffer, basic_block bb)
 {
-  gimple *stmt;
-
-  stmt = first_stmt (bb);
-
-  pp_string (buffer, "goto <bb ");
+  pp_string (buffer, "goto bb_");
   pp_decimal_int (buffer, bb->index);
-  pp_greater (buffer);
-  if (stmt && gimple_code (stmt) == GIMPLE_LABEL)
-    {
-      pp_string (buffer, " (");
-      dump_generic_node (buffer,
-			 gimple_label_label (as_a <glabel *> (stmt)),
-			 0, 0, false);
-      pp_right_paren (buffer);
-      pp_semicolon (buffer);
-    }
-  else
-    pp_semicolon (buffer);
+  pp_semicolon (buffer);
 }
 
 
diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
index 04e46fd..67ee591 100644
--- a/gcc/tree-cfg.c
+++ b/gcc/tree-cfg.c
@@ -7417,7 +7417,8 @@ dump_function_to_file (tree fndecl, FILE *file, int flags)
     }
 
   current_function_decl = fndecl;
-  fprintf (file, "%s %s(", function_name (fun), tmclone ? "[tm-clone] " : "");
+  print_generic_expr (file, TREE_TYPE (TREE_TYPE (fndecl)), dump_flags);
+  fprintf (file, "\n%s %s(", function_name (fun), tmclone ? "[tm-clone] " : "");
 
   arg = DECL_ARGUMENTS (fndecl);
   while (arg)
@@ -7484,6 +7485,7 @@ dump_function_to_file (tree fndecl, FILE *file, int flags)
 	    }
 	}
 
+#if 0
       if (!vec_safe_is_empty (fun->local_decls))
 	FOR_EACH_LOCAL_DECL (fun, ix, var)
 	  {
@@ -7494,11 +7496,12 @@ dump_function_to_file (tree fndecl, FILE *file, int flags)
 
 	    any_var = true;
 	  }
+#endif
       if (gimple_in_ssa_p (cfun))
 	for (ix = 1; ix < num_ssa_names; ++ix)
 	  {
 	    tree name = ssa_name (ix);
-	    if (name && !SSA_NAME_VAR (name))
+	    if (!virtual_operand_p (name))
 	      {
 		fprintf (file, "  ");
 		print_generic_expr (file, TREE_TYPE (name), flags);
diff --git a/gcc/tree-pretty-print.c b/gcc/tree-pretty-print.c
index 9c13d84..b2ea824 100644
--- a/gcc/tree-pretty-print.c
+++ b/gcc/tree-pretty-print.c
@@ -191,7 +191,7 @@ dump_decl_name (pretty_printer *pp, tree node, int flags)
 	  if (flags & TDF_NOUID)
 	    pp_printf (pp, "%c.xxxx", c);
 	  else
-	    pp_printf (pp, "%c.%u", c, DECL_UID (node));
+	    pp_printf (pp, "%c_%u", c, DECL_UID (node));
 	}
     }
   if ((flags & TDF_ALIAS) && DECL_PT_UID (node) != DECL_UID (node))
@@ -2597,10 +2597,12 @@ dump_generic_node (pretty_printer *pp, tree node, int spc, int flags,
 			   spc, flags, false);
       pp_underscore (pp);
       pp_decimal_int (pp, SSA_NAME_VERSION (node));
+#if 0
       if (SSA_NAME_IS_DEFAULT_DEF (node))
 	pp_string (pp, "(D)");
       if (SSA_NAME_OCCURS_IN_ABNORMAL_PHI (node))
 	pp_string (pp, "(ab)");
+#endif
       break;
 
     case WITH_SIZE_EXPR:
@@ -3861,14 +3863,14 @@ dump_function_header (FILE *dump_file, tree fdecl, int flags)
   else
     aname = "<unset-asm-name>";
 
-  fprintf (dump_file, "\n;; Function %s (%s, funcdef_no=%d",
+  fprintf (dump_file, "\n/* Function %s (%s, funcdef_no=%d",
 	   dname, aname, fun->funcdef_no);
   if (!(flags & TDF_NOUID))
     fprintf (dump_file, ", decl_uid=%d", DECL_UID (fdecl));
   if (node)
     {
       fprintf (dump_file, ", cgraph_uid=%d", node->uid);
-      fprintf (dump_file, ", symbol_order=%d)%s\n\n", node->order,
+      fprintf (dump_file, ", symbol_order=%d)%s", node->order,
                node->frequency == NODE_FREQUENCY_HOT
                ? " (hot)"
                : node->frequency == NODE_FREQUENCY_UNLIKELY_EXECUTED
@@ -3878,7 +3880,9 @@ dump_function_header (FILE *dump_file, tree fdecl, int flags)
                : "");
     }
   else
-    fprintf (dump_file, ")\n\n");
+    fprintf (dump_file, ")");
+
+  fprintf (dump_file, " */\n\n");
 }
 
 /* Dump double_int D to pretty_printer PP.  UNS is true
diff --git a/test-loop.c b/test-loop.c
new file mode 100644
index 0000000..ebb8aef
--- /dev/null
+++ b/test-loop.c
@@ -0,0 +1,31 @@
+int test_1 (int i, int j, int k)
+{
+  if (i < j)
+    return k + 4;
+  else
+    return -k;
+}
+
+/* Example showing:
+   - data structure
+   - loop
+   - call to "abort".  */
+
+struct foo
+{
+  int count;
+  float *data;
+};
+
+float test_2 (struct foo *lhs, struct foo *rhs)
+{
+  float result = 0.0f;
+
+  if (lhs->count != rhs->count)
+    __builtin_abort ();
+
+  for (int i = 0; i < lhs->count; i++)
+    result += lhs->data[i] * rhs->data[i];
+
+  return result;
+}
diff --git a/test-loop.c.018t.ssa b/test-loop.c.018t.ssa
new file mode 100644
index 0000000..bd907c1
--- /dev/null
+++ b/test-loop.c.018t.ssa
@@ -0,0 +1,114 @@
+
+/* Function test_1 (test_1, funcdef_no=0, decl_uid=1758, cgraph_uid=0, symbol_order=0) */
+
+int
+test_1 (int i, int j, int k)
+{
+  int _1;
+  int i_2;
+  int j_3;
+  int k_4;
+  int _5;
+  int _6;
+
+  bb_2:
+  if (i_2 < j_3)
+    goto bb_3;
+  else
+    goto bb_4;
+
+  bb_3:
+  _5 = k_4 + 4;
+  goto bb_5;
+
+  bb_4:
+  _6 = -k_4;
+
+  bb_5:
+  _1 = __PHI (/* bb_3:*/_5, /* bb_4:*/_6);
+label_2:
+  return _1;
+
+}
+
+
+
+/* Function test_2 (test_2, funcdef_no=1, decl_uid=1765, cgraph_uid=1, symbol_order=1) */
+
+float
+test_2 (struct foo * lhs, struct foo * rhs)
+{
+  float result_1;
+  int i_2;
+  float result_3;
+  struct foo * lhs_5;
+  int _6;
+  struct foo * rhs_7;
+  int _8;
+  int i_9;
+  int _10;
+  float * _11;
+  long unsigned int _12;
+  long unsigned int _13;
+  float * _14;
+  float _15;
+  float * _16;
+  long unsigned int _17;
+  long unsigned int _18;
+  float * _19;
+  float _20;
+  float _21;
+  float result_22;
+  int i_23;
+  float _24;
+
+  bb_2:
+  result_3 = 0.0;
+  _6 = lhs_5->count;
+  _8 = rhs_7->count;
+  if (_6 != _8)
+    goto bb_3;
+  else
+    goto bb_4;
+
+  bb_3:
+  __builtin_abort ();
+
+  bb_4:
+  i_9 = 0;
+  goto bb_6;
+
+  bb_5:
+  _11 = lhs_5->data;
+  _12 = (long unsigned int) i_2;
+  _13 = _12 * 4;
+  _14 = _11 + _13;
+  _15 = *_14;
+  _16 = rhs_7->data;
+  _17 = (long unsigned int) i_2;
+  _18 = _17 * 4;
+  _19 = _16 + _18;
+  _20 = *_19;
+  _21 = _15 * _20;
+  result_22 = _21 + result_1;
+  i_23 = i_2 + 1;
+
+  bb_6:
+  result_1 = __PHI (/* bb_4:*/result_3, /* bb_5:*/result_22);
+  i_2 = __PHI (/* bb_4:*/i_9, /* bb_5:*/i_23);
+  _10 = lhs_5->count;
+  if (_10 > i_2)
+    goto bb_5;
+  else
+    goto bb_7;
+
+  bb_7:
+  _24 = result_1;
+
+  bb_8:
+label_5:
+  return _24;
+
+}
+
+

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

[Michael Matz]

Hi,

On Thu, 10 Mar 2016, Richard Biener wrote:

> 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).

I think it's wrong to try to shoehorn the gimple FE into the C FE.  C is 
fundamentally different from gimple and you'd have to sprinkle 
gimple_dialect_p() all over the place, and maintaining that while 
developing future C improvements will turn out to be much work.  Some 
differences of C and gimple:

* C has recursive expressions, gimple is n-op stmts, no expressions at all
* C has type promotions, gimple is explicit
* C has all other kinds of automatic conversion (e.g. pointer decay)
* C has scopes, gimple doesn't (well, global and local only), i.e. symbol 
  lookup is much more complicated
* C doesn't have exceptions
* C doesn't have class types, gimple has
* C doesn't have SSA (yes, I'm aware of your suggestions for that)
* C doesn't have self-referential types
* C FE generates GENERIC, not GIMPLE (so you'd need to go through the
  gimplifier and again would feed gimple directly into the passes)

I really don't think changing the C FE to accept gimple is a useful way 
forward.

I agree with others that the gimple FE is rather more similar to a textual 
form of LTO bytecode.  In difference to the byte code its syntax has to be 
defined and kept stable, and yes, it's sensible to get inspiration from C 
syntax.

> 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.

So, you think the advantage of starting with the C FE would be faster 
return on investment?  Even if it were true (and I'm not sure it is), what 
would it help if it ultimately wouldn't be acceptable for inclusion in GCC 
proper?

> 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).

Btw. I'm not suggesting to fit the gimple FE into the LTO infrastructure, 
that's also leading to a mess IMO.  But I do think creating a gimple FE 
from scratch is easier than fitting it into the C FE.  Taking some 
infrastructure from the LTO frontend (namely all the tree/gimple building 
routines) and some from the C frontend (namely parts of the parsers, at 
least for types).

> 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.

Okay, here's a rough plan:

1) take the LTO frontend, remove all bytecode 
   routines, partitioning stuff, lto symtab merging stuff, tree merging 
   stuff, WPA stuff; i.e. retain only the few pieces needed for creating 
   tree and those that every frontend needs to provide.  Now that 
   frontend should be able to generate an empty compilation unit.
2) implement two stub functions: parsetype and lookuptype, the first 
   always generates a type named 'int32' with the obvious INTEGER_TYPE 
   tree, the second always gives back that type.  Now hack on the frontend
   long enough that this simple input can be parsed and the obvious asm 
   file is generated: "int32 i;".  Then "int32 i = 0;".

   Now the frontend knows global decls and initializers, but the type
   parsing problem is deferred.
3) implement function parsing.  Hack on the frontend long enough
   that this program is accepted and generates the obvious gimple:
     int32 main(int32 argc) {
       int32 a;
       a_1 = argc_0;
       _2 = a_1 - argc_0;
       return _2;
     }
   While doing this, think about how to represent default defs, and 
   generally SSA names.
4) implement some more operators for one and two-op statements
5) implement syntax for conditional code, for instance:
     {
       L0: if (argc_0 == 1) goto L1; else goto L2;
       L1: $preds (L0)
           return 1;
       L2: $preds (L0)
           return 2;
     }
5) think about and implement syntax for PHI nodes, e.g.:
     {
       int a;
       L0: if (argc_0 == 1) goto L1; else goto L2;
       L1: $preds (L0)
           a_1 = 1;
           goto L3;
       L2: $preds (L0)
           a_2 = 42 + argc_0;
           goto L3;
       L3: $preds (L1, L2)
           a_3 = $phi (a_1, a_2);
           return a_3;
     }

   See for instance how it's important above that all destinations that
   are reached by multiple gotos make the order of incoming edges 
   explicit.  It can't be left implicit (or needs very strict and 
   checkable rules).
6) implement function calls, requires parsing global function decls (still 
   only using 'int' types) and parsing/generating gcall insns.
7) implement more scalar base types, including pointers,
   add parsing/generating conversion statements
8) think about and implement syntax for _specifying_ layout of scalar 
   types, as well as attributes (i.e. how to say that type "T" in an
   signed integer type of 47 bits, aligned 8 bit, size 64 bits)
9) think about and implement syntax for aggregate types
10) implement more parsing for accessing elements of aggregate types
11) hack on the whole think long enough that this can be parsed and 
    generates the obvious gimple:

    type T1 *char;
    type T2 const C1;
    type T3 (C2, ...) : int;  // function type
    decl T3 *printf;
    type T {int a[10];}
    T x;
    int main(int argc, char *argv[]) {
      T *t;
      t_1 = &x;
      t_1->a[0] = argc_0;
      printf ("you passed %d arguments\n", t1->a[0]);
      return 0;
    }

Some of the later steps can be done in different order.

I think this would give enough to do for GSoC, but with mentoring 
(especially with the first part, stripping down the LTO frontend to 
something trivial) it seems achievable.  Bonus: implement exceptions, 
implement generic mean to annotate either statements or types or decls, 
implement parsing the various GCC builtins.

Obviously our gimple dumper should be amended to also be able to emit 
whatever syntax is decided in the course of implementation.  In the 
process focus should be on generatic a grammar that's easy to parse while 
retaining some visual pleasance (not all of the above might be good 
examples).  At least the gimple statement syntax should probably be quite 
similar to our current dump format.  At least during development we 
shouldn't fear revamping the syntax even severely if it furthers those 
goals, even if testcases then need to be thrown away.


Ciao,
Michael.

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

[Richard Biener]

On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Thu, 10 Mar 2016, Richard Biener wrote:
>
>> 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).
>
> I think it's wrong to try to shoehorn the gimple FE into the C FE.  C is
> fundamentally different from gimple and you'd have to sprinkle
> gimple_dialect_p() all over the place, and maintaining that while
> developing future C improvements will turn out to be much work.  Some
> differences of C and gimple:
>
> * C has recursive expressions, gimple is n-op stmts, no expressions at all
> * C has type promotions, gimple is explicit
> * C has all other kinds of automatic conversion (e.g. pointer decay)
> * C has scopes, gimple doesn't (well, global and local only), i.e. symbol
>   lookup is much more complicated
> * C doesn't have exceptions
> * C doesn't have class types, gimple has
> * C doesn't have SSA (yes, I'm aware of your suggestions for that)
> * C doesn't have self-referential types
> * C FE generates GENERIC, not GIMPLE (so you'd need to go through the
>   gimplifier and again would feed gimple directly into the passes)
>
> I really don't think changing the C FE to accept gimple is a useful way
> forward.

So I am most worried about replicating all the complexity of types and decl
parsing for the presumably nice and small function body parser.

In private discussion we somewhat agreed (Micha - correct me ;)) that
iff the GIMPLE FE would replace the C FE function body parsing
completely (re-using name lookup infrastructure of course) and iff the
GIMPLE FE would emit GIMPLE directly (just NULL DECL_SAVED_TREE
and a GIMPLE seq in DECL_STRUCT_FUNCTION->gimple_body)
then "re-using" the C FE would be a way to greatly speed up success.

The other half of the project would then be to change the pass manager
to do something sensible with the produced GIMPLE as well as making
our dumps parseable by the GIMPLE FE.

Richard.

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

[Michael Matz]

Hi,

On Tue, 15 Mar 2016, Richard Biener wrote:

> So I am most worried about replicating all the complexity of types and 
> decl parsing for the presumably nice and small function body parser.
> 
> In private discussion we somewhat agreed (Micha - correct me ;)) that 
> iff the GIMPLE FE would replace the C FE function body parsing 
> completely (re-using name lookup infrastructure of course) and iff the 
> GIMPLE FE would emit GIMPLE directly (just NULL DECL_SAVED_TREE and a 
> GIMPLE seq in DECL_STRUCT_FUNCTION->gimple_body) then "re-using" the C 
> FE would be a way to greatly speed up success.

Yeah, that's a fair characterization of our discussion.  What I'm most 
worried about with mixing C and gimple parsing are several things:
* silently accepting C-like code that actually isn't supposed to be 
  gimple, i.e. I fear we muddle the water by attaching something to an 
  existing large blob without a very clear separation
* uglifying the C parser so much that the changes become unacceptable
* Parsing gimple, but going though GENERIC; I want to directly create
  GIMPLE

Separating the type/decl parsing and function body parsing would help with 
all three things, and will give you a working type parser without actually 
copying code around, so that's a plus.

(Of course, putting it into an existing front-end might also be less fun 
than writing one from scratch, but that's not my main point :) ).

> The other half of the project would then be to change the pass manager 
> to do something sensible with the produced GIMPLE as well as making our 
> dumps parseable by the GIMPLE FE.

Definitely the dumping part needs to be developed somewhat in lock-step 
with the parser; the pass manager infrastructure should be started 
somewhat halfway into the project, yes.


Ciao,
Michael.

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

[Prathamesh Kulkarni]

On 15 March 2016 at 20:46, Richard Biener <richard.guenther@gmail.com> wrote:
> On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz <matz@suse.de> wrote:
>> Hi,
>>
>> On Thu, 10 Mar 2016, Richard Biener wrote:
>>
>>> 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).
>>
>> I think it's wrong to try to shoehorn the gimple FE into the C FE.  C is
>> fundamentally different from gimple and you'd have to sprinkle
>> gimple_dialect_p() all over the place, and maintaining that while
>> developing future C improvements will turn out to be much work.  Some
>> differences of C and gimple:
>>
>> * C has recursive expressions, gimple is n-op stmts, no expressions at all
>> * C has type promotions, gimple is explicit
>> * C has all other kinds of automatic conversion (e.g. pointer decay)
>> * C has scopes, gimple doesn't (well, global and local only), i.e. symbol
>>   lookup is much more complicated
>> * C doesn't have exceptions
>> * C doesn't have class types, gimple has
>> * C doesn't have SSA (yes, I'm aware of your suggestions for that)
>> * C doesn't have self-referential types
>> * C FE generates GENERIC, not GIMPLE (so you'd need to go through the
>>   gimplifier and again would feed gimple directly into the passes)
>>
>> I really don't think changing the C FE to accept gimple is a useful way
>> forward.
>
> So I am most worried about replicating all the complexity of types and decl
> parsing for the presumably nice and small function body parser.
Um would it be a good idea if we separate "gimple" functions from
regular C functions,
say by annotating the function definition with "gimple" attribute ?
A "gimple" function should contain only gimple stmts and not C.
eg:
__attribute__((gimple))
void foo(void)
{
  // local decls/initializers in C
  // GIMPLE body
}
Or perhaps we could add a new keyword "gimple" telling C FE that this
is a GIMPLE function.

My intention is that we could reuse C FE for parsing types and decls
(which I suppose is the primary
motivation behind reusing C FE) and avoid mixing C statements with
GIMPLE by having a separate
GIMPLE parser for parsing GIMPLE functions.
(I suppose the GIMPLE function parser would need to do minimal parsing
of decls/types to recognize
the input is a declaration and call C parsing routines for parsing the
whole decl)
When C front-end is invoked with -fgimple it should probably only
accept functions marked as "gimple".
Does this sound reasonable ?

Thanks,
Prathamesh
>
> In private discussion we somewhat agreed (Micha - correct me ;)) that
> iff the GIMPLE FE would replace the C FE function body parsing
> completely (re-using name lookup infrastructure of course) and iff the
> GIMPLE FE would emit GIMPLE directly (just NULL DECL_SAVED_TREE
> and a GIMPLE seq in DECL_STRUCT_FUNCTION->gimple_body)
> then "re-using" the C FE would be a way to greatly speed up success.
>
> The other half of the project would then be to change the pass manager
> to do something sensible with the produced GIMPLE as well as making
> our dumps parseable by the GIMPLE FE.
>
> Richard.

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

[Richard Biener]

On Fri, Mar 18, 2016 at 6:55 AM, Prathamesh Kulkarni
<prathamesh.kulkarni@linaro.org> wrote:
> On 15 March 2016 at 20:46, Richard Biener <richard.guenther@gmail.com> wrote:
>> On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz <matz@suse.de> wrote:
>>> Hi,
>>>
>>> On Thu, 10 Mar 2016, Richard Biener wrote:
>>>
>>>> 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).
>>>
>>> I think it's wrong to try to shoehorn the gimple FE into the C FE.  C is
>>> fundamentally different from gimple and you'd have to sprinkle
>>> gimple_dialect_p() all over the place, and maintaining that while
>>> developing future C improvements will turn out to be much work.  Some
>>> differences of C and gimple:
>>>
>>> * C has recursive expressions, gimple is n-op stmts, no expressions at all
>>> * C has type promotions, gimple is explicit
>>> * C has all other kinds of automatic conversion (e.g. pointer decay)
>>> * C has scopes, gimple doesn't (well, global and local only), i.e. symbol
>>>   lookup is much more complicated
>>> * C doesn't have exceptions
>>> * C doesn't have class types, gimple has
>>> * C doesn't have SSA (yes, I'm aware of your suggestions for that)
>>> * C doesn't have self-referential types
>>> * C FE generates GENERIC, not GIMPLE (so you'd need to go through the
>>>   gimplifier and again would feed gimple directly into the passes)
>>>
>>> I really don't think changing the C FE to accept gimple is a useful way
>>> forward.
>>
>> So I am most worried about replicating all the complexity of types and decl
>> parsing for the presumably nice and small function body parser.
> Um would it be a good idea if we separate "gimple" functions from
> regular C functions,
> say by annotating the function definition with "gimple" attribute ?

Yes, that was my idea.

> A "gimple" function should contain only gimple stmts and not C.
> eg:
> __attribute__((gimple))
> void foo(void)
> {
>   // local decls/initializers in C
>   // GIMPLE body
> }
> Or perhaps we could add a new keyword "gimple" telling C FE that this
> is a GIMPLE function.

Though instead of an attribute I would indeed use a new keyword (as you
can't really ignore the attribute and it should be an error with compilers
not knowing it).  Thus sth like

void foo (void)
__GIMPLE {
}

as it's also kind-of a "definition" specifier rather than a
declaration specifier.

>
> My intention is that we could reuse C FE for parsing types and decls
> (which I suppose is the primary
> motivation behind reusing C FE) and avoid mixing C statements with
> GIMPLE by having a separate
> GIMPLE parser for parsing GIMPLE functions.
> (I suppose the GIMPLE function parser would need to do minimal parsing
> of decls/types to recognize
> the input is a declaration and call C parsing routines for parsing the
> whole decl)

Yes, eventually the C frontend provides routines that can be used
to tentatively parse declarations / types used in the function.

> When C front-end is invoked with -fgimple it should probably only
> accept functions marked as "gimple".
> Does this sound reasonable ?

I think -fgimple would only enable recognizing the __GIMPLE keyword,
I wouldn't change all defs to GIMPLE with it.

Richard.

> Thanks,
> Prathamesh
>>
>> In private discussion we somewhat agreed (Micha - correct me ;)) that
>> iff the GIMPLE FE would replace the C FE function body parsing
>> completely (re-using name lookup infrastructure of course) and iff the
>> GIMPLE FE would emit GIMPLE directly (just NULL DECL_SAVED_TREE
>> and a GIMPLE seq in DECL_STRUCT_FUNCTION->gimple_body)
>> then "re-using" the C FE would be a way to greatly speed up success.
>>
>> The other half of the project would then be to change the pass manager
>> to do something sensible with the produced GIMPLE as well as making
>> our dumps parseable by the GIMPLE FE.
>>
>> Richard.

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

[Prasad Ghangal]

Hi!

Sorry for the late reply.

I was observing gimple dumps and my initial findings are, to parse
gimple, we have to add support for following components to C FE

*basic blocks
*gimple labels and goto
*gimple phi functions
        iftmp_0_1 = PHI (ftmp_0_3, iftmp_0_4)
*gimple switch
        switch (a_1) <default: <L0>, case 1: <L1>, case 2: <L2>>

*gimple exception handling

*openmp functions like
        main._omp_fn.0 (void * .omp_data_i)

Please correct me if I am wrong. Also point out if I am missing anything




On 18 March 2016 at 14:53, Richard Biener <richard.guenther@gmail.com> wrote:
> On Fri, Mar 18, 2016 at 6:55 AM, Prathamesh Kulkarni
> <prathamesh.kulkarni@linaro.org> wrote:
>> On 15 March 2016 at 20:46, Richard Biener <richard.guenther@gmail.com> wrote:
>>> On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz <matz@suse.de> wrote:
>>>> Hi,
>>>>
>>>> On Thu, 10 Mar 2016, Richard Biener wrote:
>>>>
>>>>> 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).
>>>>
>>>> I think it's wrong to try to shoehorn the gimple FE into the C FE.  C is
>>>> fundamentally different from gimple and you'd have to sprinkle
>>>> gimple_dialect_p() all over the place, and maintaining that while
>>>> developing future C improvements will turn out to be much work.  Some
>>>> differences of C and gimple:
>>>>
>>>> * C has recursive expressions, gimple is n-op stmts, no expressions at all
>>>> * C has type promotions, gimple is explicit
>>>> * C has all other kinds of automatic conversion (e.g. pointer decay)
>>>> * C has scopes, gimple doesn't (well, global and local only), i.e. symbol
>>>>   lookup is much more complicated
>>>> * C doesn't have exceptions
>>>> * C doesn't have class types, gimple has
>>>> * C doesn't have SSA (yes, I'm aware of your suggestions for that)
>>>> * C doesn't have self-referential types
>>>> * C FE generates GENERIC, not GIMPLE (so you'd need to go through the
>>>>   gimplifier and again would feed gimple directly into the passes)
>>>>
>>>> I really don't think changing the C FE to accept gimple is a useful way
>>>> forward.
>>>
>>> So I am most worried about replicating all the complexity of types and decl
>>> parsing for the presumably nice and small function body parser.
>> Um would it be a good idea if we separate "gimple" functions from
>> regular C functions,
>> say by annotating the function definition with "gimple" attribute ?
>
> Yes, that was my idea.
>
>> A "gimple" function should contain only gimple stmts and not C.
>> eg:
>> __attribute__((gimple))
>> void foo(void)
>> {
>>   // local decls/initializers in C
>>   // GIMPLE body
>> }
>> Or perhaps we could add a new keyword "gimple" telling C FE that this
>> is a GIMPLE function.
>
> Though instead of an attribute I would indeed use a new keyword (as you
> can't really ignore the attribute and it should be an error with compilers
> not knowing it).  Thus sth like
>
> void foo (void)
> __GIMPLE {
> }
>
> as it's also kind-of a "definition" specifier rather than a
> declaration specifier.
>
>>
>> My intention is that we could reuse C FE for parsing types and decls
>> (which I suppose is the primary
>> motivation behind reusing C FE) and avoid mixing C statements with
>> GIMPLE by having a separate
>> GIMPLE parser for parsing GIMPLE functions.
>> (I suppose the GIMPLE function parser would need to do minimal parsing
>> of decls/types to recognize
>> the input is a declaration and call C parsing routines for parsing the
>> whole decl)
>
> Yes, eventually the C frontend provides routines that can be used
> to tentatively parse declarations / types used in the function.
>
>> When C front-end is invoked with -fgimple it should probably only
>> accept functions marked as "gimple".
>> Does this sound reasonable ?
>
> I think -fgimple would only enable recognizing the __GIMPLE keyword,
> I wouldn't change all defs to GIMPLE with it.
>
> Richard.
>
>> Thanks,
>> Prathamesh
>>>
>>> In private discussion we somewhat agreed (Micha - correct me ;)) that
>>> iff the GIMPLE FE would replace the C FE function body parsing
>>> completely (re-using name lookup infrastructure of course) and iff the
>>> GIMPLE FE would emit GIMPLE directly (just NULL DECL_SAVED_TREE
>>> and a GIMPLE seq in DECL_STRUCT_FUNCTION->gimple_body)
>>> then "re-using" the C FE would be a way to greatly speed up success.
>>>
>>> The other half of the project would then be to change the pass manager
>>> to do something sensible with the produced GIMPLE as well as making
>>> our dumps parseable by the GIMPLE FE.
>>>
>>> Richard.



-- 
Thanks and Regards,
Prasad Ghangal

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

[Trevor Saunders]

On Mon, Mar 21, 2016 at 04:43:35AM +0530, Prasad Ghangal wrote:
> Hi!
> 
> Sorry for the late reply.
> 
> I was observing gimple dumps and my initial findings are, to parse
> gimple, we have to add support for following components to C FE
> 
> *basic blocks

I'd think you can probably make these enough like C labels that you
don't need to do anything special in the C fe to parse these.  Just
removing the < and > gets you pretty close is that it?

> *gimple labels and goto

Similar I think.

> *gimple phi functions
>         iftmp_0_1 = PHI (ftmp_0_3, iftmp_0_4)

yesI think you need to add something here.  I think you can do it as a
builtin type function that expects its arguments to be labels or names
of variables.

> *gimple switch
>         switch (a_1) <default: <L0>, case 1: <L1>, case 2: <L2>>

I'd think we could make this more C like too.

> *gimple exception handling

yeah, though note exceptions are lowered pretty quickly so supporting
them with the explicit exception syntax probably isn't particularly
important.

> *openmp functions like
>         main._omp_fn.0 (void * .omp_data_i)

I'd think you'd want to change the duping of this some to make it easier
to tell from struct.some.member.

> Please correct me if I am wrong. Also point out if I am missing anything

I think you might need to do something about variable names?

Trev

> 
> 
> 
> 
> On 18 March 2016 at 14:53, Richard Biener <richard.guenther@gmail.com> wrote:
> > On Fri, Mar 18, 2016 at 6:55 AM, Prathamesh Kulkarni
> > <prathamesh.kulkarni@linaro.org> wrote:
> >> On 15 March 2016 at 20:46, Richard Biener <richard.guenther@gmail.com> wrote:
> >>> On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz <matz@suse.de> wrote:
> >>>> Hi,
> >>>>
> >>>> On Thu, 10 Mar 2016, Richard Biener wrote:
> >>>>
> >>>>> 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).
> >>>>
> >>>> I think it's wrong to try to shoehorn the gimple FE into the C FE.  C is
> >>>> fundamentally different from gimple and you'd have to sprinkle
> >>>> gimple_dialect_p() all over the place, and maintaining that while
> >>>> developing future C improvements will turn out to be much work.  Some
> >>>> differences of C and gimple:
> >>>>
> >>>> * C has recursive expressions, gimple is n-op stmts, no expressions at all
> >>>> * C has type promotions, gimple is explicit
> >>>> * C has all other kinds of automatic conversion (e.g. pointer decay)
> >>>> * C has scopes, gimple doesn't (well, global and local only), i.e. symbol
> >>>>   lookup is much more complicated
> >>>> * C doesn't have exceptions
> >>>> * C doesn't have class types, gimple has
> >>>> * C doesn't have SSA (yes, I'm aware of your suggestions for that)
> >>>> * C doesn't have self-referential types
> >>>> * C FE generates GENERIC, not GIMPLE (so you'd need to go through the
> >>>>   gimplifier and again would feed gimple directly into the passes)
> >>>>
> >>>> I really don't think changing the C FE to accept gimple is a useful way
> >>>> forward.
> >>>
> >>> So I am most worried about replicating all the complexity of types and decl
> >>> parsing for the presumably nice and small function body parser.
> >> Um would it be a good idea if we separate "gimple" functions from
> >> regular C functions,
> >> say by annotating the function definition with "gimple" attribute ?
> >
> > Yes, that was my idea.
> >
> >> A "gimple" function should contain only gimple stmts and not C.
> >> eg:
> >> __attribute__((gimple))
> >> void foo(void)
> >> {
> >>   // local decls/initializers in C
> >>   // GIMPLE body
> >> }
> >> Or perhaps we could add a new keyword "gimple" telling C FE that this
> >> is a GIMPLE function.
> >
> > Though instead of an attribute I would indeed use a new keyword (as you
> > can't really ignore the attribute and it should be an error with compilers
> > not knowing it).  Thus sth like
> >
> > void foo (void)
> > __GIMPLE {
> > }
> >
> > as it's also kind-of a "definition" specifier rather than a
> > declaration specifier.
> >
> >>
> >> My intention is that we could reuse C FE for parsing types and decls
> >> (which I suppose is the primary
> >> motivation behind reusing C FE) and avoid mixing C statements with
> >> GIMPLE by having a separate
> >> GIMPLE parser for parsing GIMPLE functions.
> >> (I suppose the GIMPLE function parser would need to do minimal parsing
> >> of decls/types to recognize
> >> the input is a declaration and call C parsing routines for parsing the
> >> whole decl)
> >
> > Yes, eventually the C frontend provides routines that can be used
> > to tentatively parse declarations / types used in the function.
> >
> >> When C front-end is invoked with -fgimple it should probably only
> >> accept functions marked as "gimple".
> >> Does this sound reasonable ?
> >
> > I think -fgimple would only enable recognizing the __GIMPLE keyword,
> > I wouldn't change all defs to GIMPLE with it.
> >
> > Richard.
> >
> >> Thanks,
> >> Prathamesh
> >>>
> >>> In private discussion we somewhat agreed (Micha - correct me ;)) that
> >>> iff the GIMPLE FE would replace the C FE function body parsing
> >>> completely (re-using name lookup infrastructure of course) and iff the
> >>> GIMPLE FE would emit GIMPLE directly (just NULL DECL_SAVED_TREE
> >>> and a GIMPLE seq in DECL_STRUCT_FUNCTION->gimple_body)
> >>> then "re-using" the C FE would be a way to greatly speed up success.
> >>>
> >>> The other half of the project would then be to change the pass manager
> >>> to do something sensible with the produced GIMPLE as well as making
> >>> our dumps parseable by the GIMPLE FE.
> >>>
> >>> Richard.
> 
> 
> 
> -- 
> Thanks and Regards,
> Prasad Ghangal

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

[Prasad Ghangal]

Hi!

How exactly can we achieve start stop compilation on specific pass (ie
run single pass on input)?

eg. $cgimple -ftree-copyrename foo.c

should produce optimization result of -ftree-copyrename pass on foo.c input



On 21 March 2016 at 09:05, Trevor Saunders <tbsaunde@tbsaunde.org> wrote:
> On Mon, Mar 21, 2016 at 04:43:35AM +0530, Prasad Ghangal wrote:
>> Hi!
>>
>> Sorry for the late reply.
>>
>> I was observing gimple dumps and my initial findings are, to parse
>> gimple, we have to add support for following components to C FE
>>
>> *basic blocks
>
> I'd think you can probably make these enough like C labels that you
> don't need to do anything special in the C fe to parse these.  Just
> removing the < and > gets you pretty close is that it?
>
>> *gimple labels and goto
>
> Similar I think.
>
>> *gimple phi functions
>>         iftmp_0_1 = PHI (ftmp_0_3, iftmp_0_4)
>
> yesI think you need to add something here.  I think you can do it as a
> builtin type function that expects its arguments to be labels or names
> of variables.
>
>> *gimple switch
>>         switch (a_1) <default: <L0>, case 1: <L1>, case 2: <L2>>
>
> I'd think we could make this more C like too.
>
>> *gimple exception handling
>
> yeah, though note exceptions are lowered pretty quickly so supporting
> them with the explicit exception syntax probably isn't particularly
> important.
>
>> *openmp functions like
>>         main._omp_fn.0 (void * .omp_data_i)
>
> I'd think you'd want to change the duping of this some to make it easier
> to tell from struct.some.member.
>
>> Please correct me if I am wrong. Also point out if I am missing anything
>
> I think you might need to do something about variable names?
>
> Trev
>
>>
>>
>>
>>
>> On 18 March 2016 at 14:53, Richard Biener <richard.guenther@gmail.com> wrote:
>> > On Fri, Mar 18, 2016 at 6:55 AM, Prathamesh Kulkarni
>> > <prathamesh.kulkarni@linaro.org> wrote:
>> >> On 15 March 2016 at 20:46, Richard Biener <richard.guenther@gmail.com> wrote:
>> >>> On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz <matz@suse.de> wrote:
>> >>>> Hi,
>> >>>>
>> >>>> On Thu, 10 Mar 2016, Richard Biener wrote:
>> >>>>
>> >>>>> 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).
>> >>>>
>> >>>> I think it's wrong to try to shoehorn the gimple FE into the C FE.  C is
>> >>>> fundamentally different from gimple and you'd have to sprinkle
>> >>>> gimple_dialect_p() all over the place, and maintaining that while
>> >>>> developing future C improvements will turn out to be much work.  Some
>> >>>> differences of C and gimple:
>> >>>>
>> >>>> * C has recursive expressions, gimple is n-op stmts, no expressions at all
>> >>>> * C has type promotions, gimple is explicit
>> >>>> * C has all other kinds of automatic conversion (e.g. pointer decay)
>> >>>> * C has scopes, gimple doesn't (well, global and local only), i.e. symbol
>> >>>>   lookup is much more complicated
>> >>>> * C doesn't have exceptions
>> >>>> * C doesn't have class types, gimple has
>> >>>> * C doesn't have SSA (yes, I'm aware of your suggestions for that)
>> >>>> * C doesn't have self-referential types
>> >>>> * C FE generates GENERIC, not GIMPLE (so you'd need to go through the
>> >>>>   gimplifier and again would feed gimple directly into the passes)
>> >>>>
>> >>>> I really don't think changing the C FE to accept gimple is a useful way
>> >>>> forward.
>> >>>
>> >>> So I am most worried about replicating all the complexity of types and decl
>> >>> parsing for the presumably nice and small function body parser.
>> >> Um would it be a good idea if we separate "gimple" functions from
>> >> regular C functions,
>> >> say by annotating the function definition with "gimple" attribute ?
>> >
>> > Yes, that was my idea.
>> >
>> >> A "gimple" function should contain only gimple stmts and not C.
>> >> eg:
>> >> __attribute__((gimple))
>> >> void foo(void)
>> >> {
>> >>   // local decls/initializers in C
>> >>   // GIMPLE body
>> >> }
>> >> Or perhaps we could add a new keyword "gimple" telling C FE that this
>> >> is a GIMPLE function.
>> >
>> > Though instead of an attribute I would indeed use a new keyword (as you
>> > can't really ignore the attribute and it should be an error with compilers
>> > not knowing it).  Thus sth like
>> >
>> > void foo (void)
>> > __GIMPLE {
>> > }
>> >
>> > as it's also kind-of a "definition" specifier rather than a
>> > declaration specifier.
>> >
>> >>
>> >> My intention is that we could reuse C FE for parsing types and decls
>> >> (which I suppose is the primary
>> >> motivation behind reusing C FE) and avoid mixing C statements with
>> >> GIMPLE by having a separate
>> >> GIMPLE parser for parsing GIMPLE functions.
>> >> (I suppose the GIMPLE function parser would need to do minimal parsing
>> >> of decls/types to recognize
>> >> the input is a declaration and call C parsing routines for parsing the
>> >> whole decl)
>> >
>> > Yes, eventually the C frontend provides routines that can be used
>> > to tentatively parse declarations / types used in the function.
>> >
>> >> When C front-end is invoked with -fgimple it should probably only
>> >> accept functions marked as "gimple".
>> >> Does this sound reasonable ?
>> >
>> > I think -fgimple would only enable recognizing the __GIMPLE keyword,
>> > I wouldn't change all defs to GIMPLE with it.
>> >
>> > Richard.
>> >
>> >> Thanks,
>> >> Prathamesh
>> >>>
>> >>> In private discussion we somewhat agreed (Micha - correct me ;)) that
>> >>> iff the GIMPLE FE would replace the C FE function body parsing
>> >>> completely (re-using name lookup infrastructure of course) and iff the
>> >>> GIMPLE FE would emit GIMPLE directly (just NULL DECL_SAVED_TREE
>> >>> and a GIMPLE seq in DECL_STRUCT_FUNCTION->gimple_body)
>> >>> then "re-using" the C FE would be a way to greatly speed up success.
>> >>>
>> >>> The other half of the project would then be to change the pass manager
>> >>> to do something sensible with the produced GIMPLE as well as making
>> >>> our dumps parseable by the GIMPLE FE.
>> >>>
>> >>> Richard.
>>
>>
>>
>> --
>> Thanks and Regards,
>> Prasad Ghangal



-- 
Thanks and Regards,
Prasad Ghangal

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

[Richard Biener]

On Mon, Mar 21, 2016 at 4:35 AM, Trevor Saunders <tbsaunde@tbsaunde.org> wrote:
> On Mon, Mar 21, 2016 at 04:43:35AM +0530, Prasad Ghangal wrote:
>> Hi!
>>
>> Sorry for the late reply.
>>
>> I was observing gimple dumps and my initial findings are, to parse
>> gimple, we have to add support for following components to C FE
>>
>> *basic blocks
>
> I'd think you can probably make these enough like C labels that you
> don't need to do anything special in the C fe to parse these.  Just
> removing the < and > gets you pretty close is that it?
>
>> *gimple labels and goto
>
> Similar I think.
>
>> *gimple phi functions
>>         iftmp_0_1 = PHI (ftmp_0_3, iftmp_0_4)
>
> yesI think you need to add something here.  I think you can do it as a
> builtin type function that expects its arguments to be labels or names
> of variables.

Yes.

>> *gimple switch
>>         switch (a_1) <default: <L0>, case 1: <L1>, case 2: <L2>>
>
> I'd think we could make this more C like too.

switch (a_1) { default: goto L0; case 1: goto L1; ... }

which is what it boils down to.  And yes, we need to adjust label dumping to
dump C-parseable labels.

>> *gimple exception handling
>
> yeah, though note exceptions are lowered pretty quickly so supporting
> them with the explicit exception syntax probably isn't particularly
> important.

True - though if we lowered things already we need to dump/parse the
EH side-info present on the stmts plus the landing pads.  I'd simply defer
the issue of EH until at least some of the basic stuff works (read: not in
the GSoC project).

>> *openmp functions like
>>         main._omp_fn.0 (void * .omp_data_i)
>
> I'd think you'd want to change the duping of this some to make it easier
> to tell from struct.some.member.

it's just the way we name clones, yes.  Similar for the parameter name btw.

>> Please correct me if I am wrong. Also point out if I am missing anything
>
> I think you might need to do something about variable names?

Possibly about how we dump SSA names and how we dump local variable
declarations.

Richard.

> Trev
>
>>
>>
>>
>>
>> On 18 March 2016 at 14:53, Richard Biener <richard.guenther@gmail.com> wrote:
>> > On Fri, Mar 18, 2016 at 6:55 AM, Prathamesh Kulkarni
>> > <prathamesh.kulkarni@linaro.org> wrote:
>> >> On 15 March 2016 at 20:46, Richard Biener <richard.guenther@gmail.com> wrote:
>> >>> On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz <matz@suse.de> wrote:
>> >>>> Hi,
>> >>>>
>> >>>> On Thu, 10 Mar 2016, Richard Biener wrote:
>> >>>>
>> >>>>> 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).
>> >>>>
>> >>>> I think it's wrong to try to shoehorn the gimple FE into the C FE.  C is
>> >>>> fundamentally different from gimple and you'd have to sprinkle
>> >>>> gimple_dialect_p() all over the place, and maintaining that while
>> >>>> developing future C improvements will turn out to be much work.  Some
>> >>>> differences of C and gimple:
>> >>>>
>> >>>> * C has recursive expressions, gimple is n-op stmts, no expressions at all
>> >>>> * C has type promotions, gimple is explicit
>> >>>> * C has all other kinds of automatic conversion (e.g. pointer decay)
>> >>>> * C has scopes, gimple doesn't (well, global and local only), i.e. symbol
>> >>>>   lookup is much more complicated
>> >>>> * C doesn't have exceptions
>> >>>> * C doesn't have class types, gimple has
>> >>>> * C doesn't have SSA (yes, I'm aware of your suggestions for that)
>> >>>> * C doesn't have self-referential types
>> >>>> * C FE generates GENERIC, not GIMPLE (so you'd need to go through the
>> >>>>   gimplifier and again would feed gimple directly into the passes)
>> >>>>
>> >>>> I really don't think changing the C FE to accept gimple is a useful way
>> >>>> forward.
>> >>>
>> >>> So I am most worried about replicating all the complexity of types and decl
>> >>> parsing for the presumably nice and small function body parser.
>> >> Um would it be a good idea if we separate "gimple" functions from
>> >> regular C functions,
>> >> say by annotating the function definition with "gimple" attribute ?
>> >
>> > Yes, that was my idea.
>> >
>> >> A "gimple" function should contain only gimple stmts and not C.
>> >> eg:
>> >> __attribute__((gimple))
>> >> void foo(void)
>> >> {
>> >>   // local decls/initializers in C
>> >>   // GIMPLE body
>> >> }
>> >> Or perhaps we could add a new keyword "gimple" telling C FE that this
>> >> is a GIMPLE function.
>> >
>> > Though instead of an attribute I would indeed use a new keyword (as you
>> > can't really ignore the attribute and it should be an error with compilers
>> > not knowing it).  Thus sth like
>> >
>> > void foo (void)
>> > __GIMPLE {
>> > }
>> >
>> > as it's also kind-of a "definition" specifier rather than a
>> > declaration specifier.
>> >
>> >>
>> >> My intention is that we could reuse C FE for parsing types and decls
>> >> (which I suppose is the primary
>> >> motivation behind reusing C FE) and avoid mixing C statements with
>> >> GIMPLE by having a separate
>> >> GIMPLE parser for parsing GIMPLE functions.
>> >> (I suppose the GIMPLE function parser would need to do minimal parsing
>> >> of decls/types to recognize
>> >> the input is a declaration and call C parsing routines for parsing the
>> >> whole decl)
>> >
>> > Yes, eventually the C frontend provides routines that can be used
>> > to tentatively parse declarations / types used in the function.
>> >
>> >> When C front-end is invoked with -fgimple it should probably only
>> >> accept functions marked as "gimple".
>> >> Does this sound reasonable ?
>> >
>> > I think -fgimple would only enable recognizing the __GIMPLE keyword,
>> > I wouldn't change all defs to GIMPLE with it.
>> >
>> > Richard.
>> >
>> >> Thanks,
>> >> Prathamesh
>> >>>
>> >>> In private discussion we somewhat agreed (Micha - correct me ;)) that
>> >>> iff the GIMPLE FE would replace the C FE function body parsing
>> >>> completely (re-using name lookup infrastructure of course) and iff the
>> >>> GIMPLE FE would emit GIMPLE directly (just NULL DECL_SAVED_TREE
>> >>> and a GIMPLE seq in DECL_STRUCT_FUNCTION->gimple_body)
>> >>> then "re-using" the C FE would be a way to greatly speed up success.
>> >>>
>> >>> The other half of the project would then be to change the pass manager
>> >>> to do something sensible with the produced GIMPLE as well as making
>> >>> our dumps parseable by the GIMPLE FE.
>> >>>
>> >>> Richard.
>>
>>
>>
>> --
>> Thanks and Regards,
>> Prasad Ghangal

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

[Richard Biener]

On Tue, Mar 22, 2016 at 12:08 AM, Prasad Ghangal
<prasad.ghangal@gmail.com> wrote:
> Hi!
>
> How exactly can we achieve start stop compilation on specific pass (ie
> run single pass on input)?
>
> eg. $cgimple -ftree-copyrename foo.c
>
> should produce optimization result of -ftree-copyrename pass on foo.c input

You need pass manager support and annotate each function with information
on what passes should be run (in which order even?).  I think for the GSoC
project specifying a starting pass for each function via the source, like

__GIMPLE (tree-copyrename) void foo (void)
{
...
}

and hacking the pass manager to honor that is enough.

Richard.

>
>
> On 21 March 2016 at 09:05, Trevor Saunders <tbsaunde@tbsaunde.org> wrote:
>> On Mon, Mar 21, 2016 at 04:43:35AM +0530, Prasad Ghangal wrote:
>>> Hi!
>>>
>>> Sorry for the late reply.
>>>
>>> I was observing gimple dumps and my initial findings are, to parse
>>> gimple, we have to add support for following components to C FE
>>>
>>> *basic blocks
>>
>> I'd think you can probably make these enough like C labels that you
>> don't need to do anything special in the C fe to parse these.  Just
>> removing the < and > gets you pretty close is that it?
>>
>>> *gimple labels and goto
>>
>> Similar I think.
>>
>>> *gimple phi functions
>>>         iftmp_0_1 = PHI (ftmp_0_3, iftmp_0_4)
>>
>> yesI think you need to add something here.  I think you can do it as a
>> builtin type function that expects its arguments to be labels or names
>> of variables.
>>
>>> *gimple switch
>>>         switch (a_1) <default: <L0>, case 1: <L1>, case 2: <L2>>
>>
>> I'd think we could make this more C like too.
>>
>>> *gimple exception handling
>>
>> yeah, though note exceptions are lowered pretty quickly so supporting
>> them with the explicit exception syntax probably isn't particularly
>> important.
>>
>>> *openmp functions like
>>>         main._omp_fn.0 (void * .omp_data_i)
>>
>> I'd think you'd want to change the duping of this some to make it easier
>> to tell from struct.some.member.
>>
>>> Please correct me if I am wrong. Also point out if I am missing anything
>>
>> I think you might need to do something about variable names?
>>
>> Trev
>>
>>>
>>>
>>>
>>>
>>> On 18 March 2016 at 14:53, Richard Biener <richard.guenther@gmail.com> wrote:
>>> > On Fri, Mar 18, 2016 at 6:55 AM, Prathamesh Kulkarni
>>> > <prathamesh.kulkarni@linaro.org> wrote:
>>> >> On 15 March 2016 at 20:46, Richard Biener <richard.guenther@gmail.com> wrote:
>>> >>> On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz <matz@suse.de> wrote:
>>> >>>> Hi,
>>> >>>>
>>> >>>> On Thu, 10 Mar 2016, Richard Biener wrote:
>>> >>>>
>>> >>>>> 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).
>>> >>>>
>>> >>>> I think it's wrong to try to shoehorn the gimple FE into the C FE.  C is
>>> >>>> fundamentally different from gimple and you'd have to sprinkle
>>> >>>> gimple_dialect_p() all over the place, and maintaining that while
>>> >>>> developing future C improvements will turn out to be much work.  Some
>>> >>>> differences of C and gimple:
>>> >>>>
>>> >>>> * C has recursive expressions, gimple is n-op stmts, no expressions at all
>>> >>>> * C has type promotions, gimple is explicit
>>> >>>> * C has all other kinds of automatic conversion (e.g. pointer decay)
>>> >>>> * C has scopes, gimple doesn't (well, global and local only), i.e. symbol
>>> >>>>   lookup is much more complicated
>>> >>>> * C doesn't have exceptions
>>> >>>> * C doesn't have class types, gimple has
>>> >>>> * C doesn't have SSA (yes, I'm aware of your suggestions for that)
>>> >>>> * C doesn't have self-referential types
>>> >>>> * C FE generates GENERIC, not GIMPLE (so you'd need to go through the
>>> >>>>   gimplifier and again would feed gimple directly into the passes)
>>> >>>>
>>> >>>> I really don't think changing the C FE to accept gimple is a useful way
>>> >>>> forward.
>>> >>>
>>> >>> So I am most worried about replicating all the complexity of types and decl
>>> >>> parsing for the presumably nice and small function body parser.
>>> >> Um would it be a good idea if we separate "gimple" functions from
>>> >> regular C functions,
>>> >> say by annotating the function definition with "gimple" attribute ?
>>> >
>>> > Yes, that was my idea.
>>> >
>>> >> A "gimple" function should contain only gimple stmts and not C.
>>> >> eg:
>>> >> __attribute__((gimple))
>>> >> void foo(void)
>>> >> {
>>> >>   // local decls/initializers in C
>>> >>   // GIMPLE body
>>> >> }
>>> >> Or perhaps we could add a new keyword "gimple" telling C FE that this
>>> >> is a GIMPLE function.
>>> >
>>> > Though instead of an attribute I would indeed use a new keyword (as you
>>> > can't really ignore the attribute and it should be an error with compilers
>>> > not knowing it).  Thus sth like
>>> >
>>> > void foo (void)
>>> > __GIMPLE {
>>> > }
>>> >
>>> > as it's also kind-of a "definition" specifier rather than a
>>> > declaration specifier.
>>> >
>>> >>
>>> >> My intention is that we could reuse C FE for parsing types and decls
>>> >> (which I suppose is the primary
>>> >> motivation behind reusing C FE) and avoid mixing C statements with
>>> >> GIMPLE by having a separate
>>> >> GIMPLE parser for parsing GIMPLE functions.
>>> >> (I suppose the GIMPLE function parser would need to do minimal parsing
>>> >> of decls/types to recognize
>>> >> the input is a declaration and call C parsing routines for parsing the
>>> >> whole decl)
>>> >
>>> > Yes, eventually the C frontend provides routines that can be used
>>> > to tentatively parse declarations / types used in the function.
>>> >
>>> >> When C front-end is invoked with -fgimple it should probably only
>>> >> accept functions marked as "gimple".
>>> >> Does this sound reasonable ?
>>> >
>>> > I think -fgimple would only enable recognizing the __GIMPLE keyword,
>>> > I wouldn't change all defs to GIMPLE with it.
>>> >
>>> > Richard.
>>> >
>>> >> Thanks,
>>> >> Prathamesh
>>> >>>
>>> >>> In private discussion we somewhat agreed (Micha - correct me ;)) that
>>> >>> iff the GIMPLE FE would replace the C FE function body parsing
>>> >>> completely (re-using name lookup infrastructure of course) and iff the
>>> >>> GIMPLE FE would emit GIMPLE directly (just NULL DECL_SAVED_TREE
>>> >>> and a GIMPLE seq in DECL_STRUCT_FUNCTION->gimple_body)
>>> >>> then "re-using" the C FE would be a way to greatly speed up success.
>>> >>>
>>> >>> The other half of the project would then be to change the pass manager
>>> >>> to do something sensible with the produced GIMPLE as well as making
>>> >>> our dumps parseable by the GIMPLE FE.
>>> >>>
>>> >>> Richard.
>>>
>>>
>>>
>>> --
>>> Thanks and Regards,
>>> Prasad Ghangal
>
>
>
> --
> Thanks and Regards,
> Prasad Ghangal

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

[Prathamesh Kulkarni]

On 22 March 2016 at 16:26, Richard Biener <richard.guenther@gmail.com> wrote:
> On Tue, Mar 22, 2016 at 12:08 AM, Prasad Ghangal
> <prasad.ghangal@gmail.com> wrote:
>> Hi!
>>
>> How exactly can we achieve start stop compilation on specific pass (ie
>> run single pass on input)?
>>
>> eg. $cgimple -ftree-copyrename foo.c
>>
>> should produce optimization result of -ftree-copyrename pass on foo.c input
>
> You need pass manager support and annotate each function with information
> on what passes should be run (in which order even?).  I think for the GSoC
> project specifying a starting pass for each function via the source, like
>
> __GIMPLE (tree-copyrename) void foo (void)
> {
> ...
> }
>
> and hacking the pass manager to honor that is enough.
Um would annotating each function with pass order work for ipa passes too ?

Thanks,
Prathamesh
>
> Richard.
>
>>
>>
>> On 21 March 2016 at 09:05, Trevor Saunders <tbsaunde@tbsaunde.org> wrote:
>>> On Mon, Mar 21, 2016 at 04:43:35AM +0530, Prasad Ghangal wrote:
>>>> Hi!
>>>>
>>>> Sorry for the late reply.
>>>>
>>>> I was observing gimple dumps and my initial findings are, to parse
>>>> gimple, we have to add support for following components to C FE
>>>>
>>>> *basic blocks
>>>
>>> I'd think you can probably make these enough like C labels that you
>>> don't need to do anything special in the C fe to parse these.  Just
>>> removing the < and > gets you pretty close is that it?
>>>
>>>> *gimple labels and goto
>>>
>>> Similar I think.
>>>
>>>> *gimple phi functions
>>>>         iftmp_0_1 = PHI (ftmp_0_3, iftmp_0_4)
>>>
>>> yesI think you need to add something here.  I think you can do it as a
>>> builtin type function that expects its arguments to be labels or names
>>> of variables.
>>>
>>>> *gimple switch
>>>>         switch (a_1) <default: <L0>, case 1: <L1>, case 2: <L2>>
>>>
>>> I'd think we could make this more C like too.
>>>
>>>> *gimple exception handling
>>>
>>> yeah, though note exceptions are lowered pretty quickly so supporting
>>> them with the explicit exception syntax probably isn't particularly
>>> important.
>>>
>>>> *openmp functions like
>>>>         main._omp_fn.0 (void * .omp_data_i)
>>>
>>> I'd think you'd want to change the duping of this some to make it easier
>>> to tell from struct.some.member.
>>>
>>>> Please correct me if I am wrong. Also point out if I am missing anything
>>>
>>> I think you might need to do something about variable names?
>>>
>>> Trev
>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 18 March 2016 at 14:53, Richard Biener <richard.guenther@gmail.com> wrote:
>>>> > On Fri, Mar 18, 2016 at 6:55 AM, Prathamesh Kulkarni
>>>> > <prathamesh.kulkarni@linaro.org> wrote:
>>>> >> On 15 March 2016 at 20:46, Richard Biener <richard.guenther@gmail.com> wrote:
>>>> >>> On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz <matz@suse.de> wrote:
>>>> >>>> Hi,
>>>> >>>>
>>>> >>>> On Thu, 10 Mar 2016, Richard Biener wrote:
>>>> >>>>
>>>> >>>>> 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).
>>>> >>>>
>>>> >>>> I think it's wrong to try to shoehorn the gimple FE into the C FE.  C is
>>>> >>>> fundamentally different from gimple and you'd have to sprinkle
>>>> >>>> gimple_dialect_p() all over the place, and maintaining that while
>>>> >>>> developing future C improvements will turn out to be much work.  Some
>>>> >>>> differences of C and gimple:
>>>> >>>>
>>>> >>>> * C has recursive expressions, gimple is n-op stmts, no expressions at all
>>>> >>>> * C has type promotions, gimple is explicit
>>>> >>>> * C has all other kinds of automatic conversion (e.g. pointer decay)
>>>> >>>> * C has scopes, gimple doesn't (well, global and local only), i.e. symbol
>>>> >>>>   lookup is much more complicated
>>>> >>>> * C doesn't have exceptions
>>>> >>>> * C doesn't have class types, gimple has
>>>> >>>> * C doesn't have SSA (yes, I'm aware of your suggestions for that)
>>>> >>>> * C doesn't have self-referential types
>>>> >>>> * C FE generates GENERIC, not GIMPLE (so you'd need to go through the
>>>> >>>>   gimplifier and again would feed gimple directly into the passes)
>>>> >>>>
>>>> >>>> I really don't think changing the C FE to accept gimple is a useful way
>>>> >>>> forward.
>>>> >>>
>>>> >>> So I am most worried about replicating all the complexity of types and decl
>>>> >>> parsing for the presumably nice and small function body parser.
>>>> >> Um would it be a good idea if we separate "gimple" functions from
>>>> >> regular C functions,
>>>> >> say by annotating the function definition with "gimple" attribute ?
>>>> >
>>>> > Yes, that was my idea.
>>>> >
>>>> >> A "gimple" function should contain only gimple stmts and not C.
>>>> >> eg:
>>>> >> __attribute__((gimple))
>>>> >> void foo(void)
>>>> >> {
>>>> >>   // local decls/initializers in C
>>>> >>   // GIMPLE body
>>>> >> }
>>>> >> Or perhaps we could add a new keyword "gimple" telling C FE that this
>>>> >> is a GIMPLE function.
>>>> >
>>>> > Though instead of an attribute I would indeed use a new keyword (as you
>>>> > can't really ignore the attribute and it should be an error with compilers
>>>> > not knowing it).  Thus sth like
>>>> >
>>>> > void foo (void)
>>>> > __GIMPLE {
>>>> > }
>>>> >
>>>> > as it's also kind-of a "definition" specifier rather than a
>>>> > declaration specifier.
>>>> >
>>>> >>
>>>> >> My intention is that we could reuse C FE for parsing types and decls
>>>> >> (which I suppose is the primary
>>>> >> motivation behind reusing C FE) and avoid mixing C statements with
>>>> >> GIMPLE by having a separate
>>>> >> GIMPLE parser for parsing GIMPLE functions.
>>>> >> (I suppose the GIMPLE function parser would need to do minimal parsing
>>>> >> of decls/types to recognize
>>>> >> the input is a declaration and call C parsing routines for parsing the
>>>> >> whole decl)
>>>> >
>>>> > Yes, eventually the C frontend provides routines that can be used
>>>> > to tentatively parse declarations / types used in the function.
>>>> >
>>>> >> When C front-end is invoked with -fgimple it should probably only
>>>> >> accept functions marked as "gimple".
>>>> >> Does this sound reasonable ?
>>>> >
>>>> > I think -fgimple would only enable recognizing the __GIMPLE keyword,
>>>> > I wouldn't change all defs to GIMPLE with it.
>>>> >
>>>> > Richard.
>>>> >
>>>> >> Thanks,
>>>> >> Prathamesh
>>>> >>>
>>>> >>> In private discussion we somewhat agreed (Micha - correct me ;)) that
>>>> >>> iff the GIMPLE FE would replace the C FE function body parsing
>>>> >>> completely (re-using name lookup infrastructure of course) and iff the
>>>> >>> GIMPLE FE would emit GIMPLE directly (just NULL DECL_SAVED_TREE
>>>> >>> and a GIMPLE seq in DECL_STRUCT_FUNCTION->gimple_body)
>>>> >>> then "re-using" the C FE would be a way to greatly speed up success.
>>>> >>>
>>>> >>> The other half of the project would then be to change the pass manager
>>>> >>> to do something sensible with the produced GIMPLE as well as making
>>>> >>> our dumps parseable by the GIMPLE FE.
>>>> >>>
>>>> >>> Richard.
>>>>
>>>>
>>>>
>>>> --
>>>> Thanks and Regards,
>>>> Prasad Ghangal
>>
>>
>>
>> --
>> Thanks and Regards,
>> Prasad Ghangal

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

[Richard Biener]

On Tue, Mar 22, 2016 at 2:45 PM, Prathamesh Kulkarni
<prathamesh.kulkarni@linaro.org> wrote:
> On 22 March 2016 at 16:26, Richard Biener <richard.guenther@gmail.com> wrote:
>> On Tue, Mar 22, 2016 at 12:08 AM, Prasad Ghangal
>> <prasad.ghangal@gmail.com> wrote:
>>> Hi!
>>>
>>> How exactly can we achieve start stop compilation on specific pass (ie
>>> run single pass on input)?
>>>
>>> eg. $cgimple -ftree-copyrename foo.c
>>>
>>> should produce optimization result of -ftree-copyrename pass on foo.c input
>>
>> You need pass manager support and annotate each function with information
>> on what passes should be run (in which order even?).  I think for the GSoC
>> project specifying a starting pass for each function via the source, like
>>
>> __GIMPLE (tree-copyrename) void foo (void)
>> {
>> ...
>> }
>>
>> and hacking the pass manager to honor that is enough.
> Um would annotating each function with pass order work for ipa passes too ?

There is no single point of execution for an IPA pass so no - you can
tag it with
one of the umbrella passes I guess.  I suppose we'd need some magic "phase"
tags for this, like simply "IPA".  You then need to enable/disable IPA passes
you want to run.

Richard.

> Thanks,
> Prathamesh
>>
>> Richard.
>>
>>>
>>>
>>> On 21 March 2016 at 09:05, Trevor Saunders <tbsaunde@tbsaunde.org> wrote:
>>>> On Mon, Mar 21, 2016 at 04:43:35AM +0530, Prasad Ghangal wrote:
>>>>> Hi!
>>>>>
>>>>> Sorry for the late reply.
>>>>>
>>>>> I was observing gimple dumps and my initial findings are, to parse
>>>>> gimple, we have to add support for following components to C FE
>>>>>
>>>>> *basic blocks
>>>>
>>>> I'd think you can probably make these enough like C labels that you
>>>> don't need to do anything special in the C fe to parse these.  Just
>>>> removing the < and > gets you pretty close is that it?
>>>>
>>>>> *gimple labels and goto
>>>>
>>>> Similar I think.
>>>>
>>>>> *gimple phi functions
>>>>>         iftmp_0_1 = PHI (ftmp_0_3, iftmp_0_4)
>>>>
>>>> yesI think you need to add something here.  I think you can do it as a
>>>> builtin type function that expects its arguments to be labels or names
>>>> of variables.
>>>>
>>>>> *gimple switch
>>>>>         switch (a_1) <default: <L0>, case 1: <L1>, case 2: <L2>>
>>>>
>>>> I'd think we could make this more C like too.
>>>>
>>>>> *gimple exception handling
>>>>
>>>> yeah, though note exceptions are lowered pretty quickly so supporting
>>>> them with the explicit exception syntax probably isn't particularly
>>>> important.
>>>>
>>>>> *openmp functions like
>>>>>         main._omp_fn.0 (void * .omp_data_i)
>>>>
>>>> I'd think you'd want to change the duping of this some to make it easier
>>>> to tell from struct.some.member.
>>>>
>>>>> Please correct me if I am wrong. Also point out if I am missing anything
>>>>
>>>> I think you might need to do something about variable names?
>>>>
>>>> Trev
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 18 March 2016 at 14:53, Richard Biener <richard.guenther@gmail.com> wrote:
>>>>> > On Fri, Mar 18, 2016 at 6:55 AM, Prathamesh Kulkarni
>>>>> > <prathamesh.kulkarni@linaro.org> wrote:
>>>>> >> On 15 March 2016 at 20:46, Richard Biener <richard.guenther@gmail.com> wrote:
>>>>> >>> On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz <matz@suse.de> wrote:
>>>>> >>>> Hi,
>>>>> >>>>
>>>>> >>>> On Thu, 10 Mar 2016, Richard Biener wrote:
>>>>> >>>>
>>>>> >>>>> 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).
>>>>> >>>>
>>>>> >>>> I think it's wrong to try to shoehorn the gimple FE into the C FE.  C is
>>>>> >>>> fundamentally different from gimple and you'd have to sprinkle
>>>>> >>>> gimple_dialect_p() all over the place, and maintaining that while
>>>>> >>>> developing future C improvements will turn out to be much work.  Some
>>>>> >>>> differences of C and gimple:
>>>>> >>>>
>>>>> >>>> * C has recursive expressions, gimple is n-op stmts, no expressions at all
>>>>> >>>> * C has type promotions, gimple is explicit
>>>>> >>>> * C has all other kinds of automatic conversion (e.g. pointer decay)
>>>>> >>>> * C has scopes, gimple doesn't (well, global and local only), i.e. symbol
>>>>> >>>>   lookup is much more complicated
>>>>> >>>> * C doesn't have exceptions
>>>>> >>>> * C doesn't have class types, gimple has
>>>>> >>>> * C doesn't have SSA (yes, I'm aware of your suggestions for that)
>>>>> >>>> * C doesn't have self-referential types
>>>>> >>>> * C FE generates GENERIC, not GIMPLE (so you'd need to go through the
>>>>> >>>>   gimplifier and again would feed gimple directly into the passes)
>>>>> >>>>
>>>>> >>>> I really don't think changing the C FE to accept gimple is a useful way
>>>>> >>>> forward.
>>>>> >>>
>>>>> >>> So I am most worried about replicating all the complexity of types and decl
>>>>> >>> parsing for the presumably nice and small function body parser.
>>>>> >> Um would it be a good idea if we separate "gimple" functions from
>>>>> >> regular C functions,
>>>>> >> say by annotating the function definition with "gimple" attribute ?
>>>>> >
>>>>> > Yes, that was my idea.
>>>>> >
>>>>> >> A "gimple" function should contain only gimple stmts and not C.
>>>>> >> eg:
>>>>> >> __attribute__((gimple))
>>>>> >> void foo(void)
>>>>> >> {
>>>>> >>   // local decls/initializers in C
>>>>> >>   // GIMPLE body
>>>>> >> }
>>>>> >> Or perhaps we could add a new keyword "gimple" telling C FE that this
>>>>> >> is a GIMPLE function.
>>>>> >
>>>>> > Though instead of an attribute I would indeed use a new keyword (as you
>>>>> > can't really ignore the attribute and it should be an error with compilers
>>>>> > not knowing it).  Thus sth like
>>>>> >
>>>>> > void foo (void)
>>>>> > __GIMPLE {
>>>>> > }
>>>>> >
>>>>> > as it's also kind-of a "definition" specifier rather than a
>>>>> > declaration specifier.
>>>>> >
>>>>> >>
>>>>> >> My intention is that we could reuse C FE for parsing types and decls
>>>>> >> (which I suppose is the primary
>>>>> >> motivation behind reusing C FE) and avoid mixing C statements with
>>>>> >> GIMPLE by having a separate
>>>>> >> GIMPLE parser for parsing GIMPLE functions.
>>>>> >> (I suppose the GIMPLE function parser would need to do minimal parsing
>>>>> >> of decls/types to recognize
>>>>> >> the input is a declaration and call C parsing routines for parsing the
>>>>> >> whole decl)
>>>>> >
>>>>> > Yes, eventually the C frontend provides routines that can be used
>>>>> > to tentatively parse declarations / types used in the function.
>>>>> >
>>>>> >> When C front-end is invoked with -fgimple it should probably only
>>>>> >> accept functions marked as "gimple".
>>>>> >> Does this sound reasonable ?
>>>>> >
>>>>> > I think -fgimple would only enable recognizing the __GIMPLE keyword,
>>>>> > I wouldn't change all defs to GIMPLE with it.
>>>>> >
>>>>> > Richard.
>>>>> >
>>>>> >> Thanks,
>>>>> >> Prathamesh
>>>>> >>>
>>>>> >>> In private discussion we somewhat agreed (Micha - correct me ;)) that
>>>>> >>> iff the GIMPLE FE would replace the C FE function body parsing
>>>>> >>> completely (re-using name lookup infrastructure of course) and iff the
>>>>> >>> GIMPLE FE would emit GIMPLE directly (just NULL DECL_SAVED_TREE
>>>>> >>> and a GIMPLE seq in DECL_STRUCT_FUNCTION->gimple_body)
>>>>> >>> then "re-using" the C FE would be a way to greatly speed up success.
>>>>> >>>
>>>>> >>> The other half of the project would then be to change the pass manager
>>>>> >>> to do something sensible with the produced GIMPLE as well as making
>>>>> >>> our dumps parseable by the GIMPLE FE.
>>>>> >>>
>>>>> >>> Richard.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thanks and Regards,
>>>>> Prasad Ghangal
>>>
>>>
>>>
>>> --
>>> Thanks and Regards,
>>> Prasad Ghangal

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

[Prasad Ghangal]

Hi!

Here is the link my gsoc proposal, please review it. Let me know if I
have missed or misunderstood anything

https://drive.google.com/file/d/0B2S9OoautWxsbVBkWDY3VDNkdGc/view




Thanks and Regards,
Prasad Ghangal


On 22 March 2016 at 19:23, Richard Biener <richard.guenther@gmail.com> wrote:
> On Tue, Mar 22, 2016 at 2:45 PM, Prathamesh Kulkarni
> <prathamesh.kulkarni@linaro.org> wrote:
>> On 22 March 2016 at 16:26, Richard Biener <richard.guenther@gmail.com> wrote:
>>> On Tue, Mar 22, 2016 at 12:08 AM, Prasad Ghangal
>>> <prasad.ghangal@gmail.com> wrote:
>>>> Hi!
>>>>
>>>> How exactly can we achieve start stop compilation on specific pass (ie
>>>> run single pass on input)?
>>>>
>>>> eg. $cgimple -ftree-copyrename foo.c
>>>>
>>>> should produce optimization result of -ftree-copyrename pass on foo.c input
>>>
>>> You need pass manager support and annotate each function with information
>>> on what passes should be run (in which order even?).  I think for the GSoC
>>> project specifying a starting pass for each function via the source, like
>>>
>>> __GIMPLE (tree-copyrename) void foo (void)
>>> {
>>> ...
>>> }
>>>
>>> and hacking the pass manager to honor that is enough.
>> Um would annotating each function with pass order work for ipa passes too ?
>
> There is no single point of execution for an IPA pass so no - you can
> tag it with
> one of the umbrella passes I guess.  I suppose we'd need some magic "phase"
> tags for this, like simply "IPA".  You then need to enable/disable IPA passes
> you want to run.
>
> Richard.
>
>> Thanks,
>> Prathamesh
>>>
>>> Richard.
>>>
>>>>
>>>>
>>>> On 21 March 2016 at 09:05, Trevor Saunders <tbsaunde@tbsaunde.org> wrote:
>>>>> On Mon, Mar 21, 2016 at 04:43:35AM +0530, Prasad Ghangal wrote:
>>>>>> Hi!
>>>>>>
>>>>>> Sorry for the late reply.
>>>>>>
>>>>>> I was observing gimple dumps and my initial findings are, to parse
>>>>>> gimple, we have to add support for following components to C FE
>>>>>>
>>>>>> *basic blocks
>>>>>
>>>>> I'd think you can probably make these enough like C labels that you
>>>>> don't need to do anything special in the C fe to parse these.  Just
>>>>> removing the < and > gets you pretty close is that it?
>>>>>
>>>>>> *gimple labels and goto
>>>>>
>>>>> Similar I think.
>>>>>
>>>>>> *gimple phi functions
>>>>>>         iftmp_0_1 = PHI (ftmp_0_3, iftmp_0_4)
>>>>>
>>>>> yesI think you need to add something here.  I think you can do it as a
>>>>> builtin type function that expects its arguments to be labels or names
>>>>> of variables.
>>>>>
>>>>>> *gimple switch
>>>>>>         switch (a_1) <default: <L0>, case 1: <L1>, case 2: <L2>>
>>>>>
>>>>> I'd think we could make this more C like too.
>>>>>
>>>>>> *gimple exception handling
>>>>>
>>>>> yeah, though note exceptions are lowered pretty quickly so supporting
>>>>> them with the explicit exception syntax probably isn't particularly
>>>>> important.
>>>>>
>>>>>> *openmp functions like
>>>>>>         main._omp_fn.0 (void * .omp_data_i)
>>>>>
>>>>> I'd think you'd want to change the duping of this some to make it easier
>>>>> to tell from struct.some.member.
>>>>>
>>>>>> Please correct me if I am wrong. Also point out if I am missing anything
>>>>>
>>>>> I think you might need to do something about variable names?
>>>>>
>>>>> Trev
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 18 March 2016 at 14:53, Richard Biener <richard.guenther@gmail.com> wrote:
>>>>>> > On Fri, Mar 18, 2016 at 6:55 AM, Prathamesh Kulkarni
>>>>>> > <prathamesh.kulkarni@linaro.org> wrote:
>>>>>> >> On 15 March 2016 at 20:46, Richard Biener <richard.guenther@gmail.com> wrote:
>>>>>> >>> On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz <matz@suse.de> wrote:
>>>>>> >>>> Hi,
>>>>>> >>>>
>>>>>> >>>> On Thu, 10 Mar 2016, Richard Biener wrote:
>>>>>> >>>>
>>>>>> >>>>> 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).
>>>>>> >>>>
>>>>>> >>>> I think it's wrong to try to shoehorn the gimple FE into the C FE.  C is
>>>>>> >>>> fundamentally different from gimple and you'd have to sprinkle
>>>>>> >>>> gimple_dialect_p() all over the place, and maintaining that while
>>>>>> >>>> developing future C improvements will turn out to be much work.  Some
>>>>>> >>>> differences of C and gimple:
>>>>>> >>>>
>>>>>> >>>> * C has recursive expressions, gimple is n-op stmts, no expressions at all
>>>>>> >>>> * C has type promotions, gimple is explicit
>>>>>> >>>> * C has all other kinds of automatic conversion (e.g. pointer decay)
>>>>>> >>>> * C has scopes, gimple doesn't (well, global and local only), i.e. symbol
>>>>>> >>>>   lookup is much more complicated
>>>>>> >>>> * C doesn't have exceptions
>>>>>> >>>> * C doesn't have class types, gimple has
>>>>>> >>>> * C doesn't have SSA (yes, I'm aware of your suggestions for that)
>>>>>> >>>> * C doesn't have self-referential types
>>>>>> >>>> * C FE generates GENERIC, not GIMPLE (so you'd need to go through the
>>>>>> >>>>   gimplifier and again would feed gimple directly into the passes)
>>>>>> >>>>
>>>>>> >>>> I really don't think changing the C FE to accept gimple is a useful way
>>>>>> >>>> forward.
>>>>>> >>>
>>>>>> >>> So I am most worried about replicating all the complexity of types and decl
>>>>>> >>> parsing for the presumably nice and small function body parser.
>>>>>> >> Um would it be a good idea if we separate "gimple" functions from
>>>>>> >> regular C functions,
>>>>>> >> say by annotating the function definition with "gimple" attribute ?
>>>>>> >
>>>>>> > Yes, that was my idea.
>>>>>> >
>>>>>> >> A "gimple" function should contain only gimple stmts and not C.
>>>>>> >> eg:
>>>>>> >> __attribute__((gimple))
>>>>>> >> void foo(void)
>>>>>> >> {
>>>>>> >>   // local decls/initializers in C
>>>>>> >>   // GIMPLE body
>>>>>> >> }
>>>>>> >> Or perhaps we could add a new keyword "gimple" telling C FE that this
>>>>>> >> is a GIMPLE function.
>>>>>> >
>>>>>> > Though instead of an attribute I would indeed use a new keyword (as you
>>>>>> > can't really ignore the attribute and it should be an error with compilers
>>>>>> > not knowing it).  Thus sth like
>>>>>> >
>>>>>> > void foo (void)
>>>>>> > __GIMPLE {
>>>>>> > }
>>>>>> >
>>>>>> > as it's also kind-of a "definition" specifier rather than a
>>>>>> > declaration specifier.
>>>>>> >
>>>>>> >>
>>>>>> >> My intention is that we could reuse C FE for parsing types and decls
>>>>>> >> (which I suppose is the primary
>>>>>> >> motivation behind reusing C FE) and avoid mixing C statements with
>>>>>> >> GIMPLE by having a separate
>>>>>> >> GIMPLE parser for parsing GIMPLE functions.
>>>>>> >> (I suppose the GIMPLE function parser would need to do minimal parsing
>>>>>> >> of decls/types to recognize
>>>>>> >> the input is a declaration and call C parsing routines for parsing the
>>>>>> >> whole decl)
>>>>>> >
>>>>>> > Yes, eventually the C frontend provides routines that can be used
>>>>>> > to tentatively parse declarations / types used in the function.
>>>>>> >
>>>>>> >> When C front-end is invoked with -fgimple it should probably only
>>>>>> >> accept functions marked as "gimple".
>>>>>> >> Does this sound reasonable ?
>>>>>> >
>>>>>> > I think -fgimple would only enable recognizing the __GIMPLE keyword,
>>>>>> > I wouldn't change all defs to GIMPLE with it.
>>>>>> >
>>>>>> > Richard.
>>>>>> >
>>>>>> >> Thanks,
>>>>>> >> Prathamesh
>>>>>> >>>
>>>>>> >>> In private discussion we somewhat agreed (Micha - correct me ;)) that
>>>>>> >>> iff the GIMPLE FE would replace the C FE function body parsing
>>>>>> >>> completely (re-using name lookup infrastructure of course) and iff the
>>>>>> >>> GIMPLE FE would emit GIMPLE directly (just NULL DECL_SAVED_TREE
>>>>>> >>> and a GIMPLE seq in DECL_STRUCT_FUNCTION->gimple_body)
>>>>>> >>> then "re-using" the C FE would be a way to greatly speed up success.
>>>>>> >>>
>>>>>> >>> The other half of the project would then be to change the pass manager
>>>>>> >>> to do something sensible with the produced GIMPLE as well as making
>>>>>> >>> our dumps parseable by the GIMPLE FE.
>>>>>> >>>
>>>>>> >>> Richard.
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Thanks and Regards,
>>>>>> Prasad Ghangal
>>>>
>>>>
>>>>
>>>> --
>>>> Thanks and Regards,
>>>> Prasad Ghangal

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

[Richard Biener]

On Thu, Mar 24, 2016 at 12:27 AM, Prasad Ghangal
<prasad.ghangal@gmail.com> wrote:
> Hi!
>
> I have attached my gsoc proposal, please review it. Let me know if I
> have missed or misunderstood anything

Please re-word the Abstract, it is really weird to read - I suggest to drop
any notion of RTL or "back end" and somehow mention that unit testing
is why "we want make changes in GIMPLE".  Also stopping compilation
isn't in the scope of the project (and while maybe a nice thing to have
to do less work it is not a requirement for unit testing).

Thus Project Goals are only unit testing (which includes what you call
start/stop compilation).

During the discussion in the last comments we agreed on re-using the
C frontend for decls and types only and implement a completely separate
parser for the function bodies so the frontend can also emit GIMPLE directly.

Thus I'd scrap 4.A)/B) and instead write about

  4.
    A) Define GIMPLE syntax
    Provide GIMPLE dumps with enough information to parse GIMPLE and
    change them according to agreed on GIMPLE syntax

    B) Add __GIMPLE extension to the C FE and implement a GIMPLE parser

For the suggested timeline I think that it is important for the "get
basic stuff working"
part to have all pieces of the project prototyped, including the pass manager
support.  Otherwise there is no way to fully test part of the implementation.
I'd say modifying the gimple dumps can be done last as you can always write
testcases manually.

I realize that the student application deadline is tomorrow.

Richard.



>
> Thanks and Regards,
> Prasad Ghangal
>
>
>
>
>
> On 22 March 2016 at 19:23, Richard Biener <richard.guenther@gmail.com> wrote:
>> On Tue, Mar 22, 2016 at 2:45 PM, Prathamesh Kulkarni
>> <prathamesh.kulkarni@linaro.org> wrote:
>>> On 22 March 2016 at 16:26, Richard Biener <richard.guenther@gmail.com> wrote:
>>>> On Tue, Mar 22, 2016 at 12:08 AM, Prasad Ghangal
>>>> <prasad.ghangal@gmail.com> wrote:
>>>>> Hi!
>>>>>
>>>>> How exactly can we achieve start stop compilation on specific pass (ie
>>>>> run single pass on input)?
>>>>>
>>>>> eg. $cgimple -ftree-copyrename foo.c
>>>>>
>>>>> should produce optimization result of -ftree-copyrename pass on foo.c input
>>>>
>>>> You need pass manager support and annotate each function with information
>>>> on what passes should be run (in which order even?).  I think for the GSoC
>>>> project specifying a starting pass for each function via the source, like
>>>>
>>>> __GIMPLE (tree-copyrename) void foo (void)
>>>> {
>>>> ...
>>>> }
>>>>
>>>> and hacking the pass manager to honor that is enough.
>>> Um would annotating each function with pass order work for ipa passes too ?
>>
>> There is no single point of execution for an IPA pass so no - you can
>> tag it with
>> one of the umbrella passes I guess.  I suppose we'd need some magic "phase"
>> tags for this, like simply "IPA".  You then need to enable/disable IPA passes
>> you want to run.
>>
>> Richard.
>>
>>> Thanks,
>>> Prathamesh
>>>>
>>>> Richard.
>>>>
>>>>>
>>>>>
>>>>> On 21 March 2016 at 09:05, Trevor Saunders <tbsaunde@tbsaunde.org> wrote:
>>>>>> On Mon, Mar 21, 2016 at 04:43:35AM +0530, Prasad Ghangal wrote:
>>>>>>> Hi!
>>>>>>>
>>>>>>> Sorry for the late reply.
>>>>>>>
>>>>>>> I was observing gimple dumps and my initial findings are, to parse
>>>>>>> gimple, we have to add support for following components to C FE
>>>>>>>
>>>>>>> *basic blocks
>>>>>>
>>>>>> I'd think you can probably make these enough like C labels that you
>>>>>> don't need to do anything special in the C fe to parse these.  Just
>>>>>> removing the < and > gets you pretty close is that it?
>>>>>>
>>>>>>> *gimple labels and goto
>>>>>>
>>>>>> Similar I think.
>>>>>>
>>>>>>> *gimple phi functions
>>>>>>>         iftmp_0_1 = PHI (ftmp_0_3, iftmp_0_4)
>>>>>>
>>>>>> yesI think you need to add something here.  I think you can do it as a
>>>>>> builtin type function that expects its arguments to be labels or names
>>>>>> of variables.
>>>>>>
>>>>>>> *gimple switch
>>>>>>>         switch (a_1) <default: <L0>, case 1: <L1>, case 2: <L2>>
>>>>>>
>>>>>> I'd think we could make this more C like too.
>>>>>>
>>>>>>> *gimple exception handling
>>>>>>
>>>>>> yeah, though note exceptions are lowered pretty quickly so supporting
>>>>>> them with the explicit exception syntax probably isn't particularly
>>>>>> important.
>>>>>>
>>>>>>> *openmp functions like
>>>>>>>         main._omp_fn.0 (void * .omp_data_i)
>>>>>>
>>>>>> I'd think you'd want to change the duping of this some to make it easier
>>>>>> to tell from struct.some.member.
>>>>>>
>>>>>>> Please correct me if I am wrong. Also point out if I am missing anything
>>>>>>
>>>>>> I think you might need to do something about variable names?
>>>>>>
>>>>>> Trev
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 18 March 2016 at 14:53, Richard Biener <richard.guenther@gmail.com> wrote:
>>>>>>> > On Fri, Mar 18, 2016 at 6:55 AM, Prathamesh Kulkarni
>>>>>>> > <prathamesh.kulkarni@linaro.org> wrote:
>>>>>>> >> On 15 March 2016 at 20:46, Richard Biener <richard.guenther@gmail.com> wrote:
>>>>>>> >>> On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz <matz@suse.de> wrote:
>>>>>>> >>>> Hi,
>>>>>>> >>>>
>>>>>>> >>>> On Thu, 10 Mar 2016, Richard Biener wrote:
>>>>>>> >>>>
>>>>>>> >>>>> 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).
>>>>>>> >>>>
>>>>>>> >>>> I think it's wrong to try to shoehorn the gimple FE into the C FE.  C is
>>>>>>> >>>> fundamentally different from gimple and you'd have to sprinkle
>>>>>>> >>>> gimple_dialect_p() all over the place, and maintaining that while
>>>>>>> >>>> developing future C improvements will turn out to be much work.  Some
>>>>>>> >>>> differences of C and gimple:
>>>>>>> >>>>
>>>>>>> >>>> * C has recursive expressions, gimple is n-op stmts, no expressions at all
>>>>>>> >>>> * C has type promotions, gimple is explicit
>>>>>>> >>>> * C has all other kinds of automatic conversion (e.g. pointer decay)
>>>>>>> >>>> * C has scopes, gimple doesn't (well, global and local only), i.e. symbol
>>>>>>> >>>>   lookup is much more complicated
>>>>>>> >>>> * C doesn't have exceptions
>>>>>>> >>>> * C doesn't have class types, gimple has
>>>>>>> >>>> * C doesn't have SSA (yes, I'm aware of your suggestions for that)
>>>>>>> >>>> * C doesn't have self-referential types
>>>>>>> >>>> * C FE generates GENERIC, not GIMPLE (so you'd need to go through the
>>>>>>> >>>>   gimplifier and again would feed gimple directly into the passes)
>>>>>>> >>>>
>>>>>>> >>>> I really don't think changing the C FE to accept gimple is a useful way
>>>>>>> >>>> forward.
>>>>>>> >>>
>>>>>>> >>> So I am most worried about replicating all the complexity of types and decl
>>>>>>> >>> parsing for the presumably nice and small function body parser.
>>>>>>> >> Um would it be a good idea if we separate "gimple" functions from
>>>>>>> >> regular C functions,
>>>>>>> >> say by annotating the function definition with "gimple" attribute ?
>>>>>>> >
>>>>>>> > Yes, that was my idea.
>>>>>>> >
>>>>>>> >> A "gimple" function should contain only gimple stmts and not C.
>>>>>>> >> eg:
>>>>>>> >> __attribute__((gimple))
>>>>>>> >> void foo(void)
>>>>>>> >> {
>>>>>>> >>   // local decls/initializers in C
>>>>>>> >>   // GIMPLE body
>>>>>>> >> }
>>>>>>> >> Or perhaps we could add a new keyword "gimple" telling C FE that this
>>>>>>> >> is a GIMPLE function.
>>>>>>> >
>>>>>>> > Though instead of an attribute I would indeed use a new keyword (as you
>>>>>>> > can't really ignore the attribute and it should be an error with compilers
>>>>>>> > not knowing it).  Thus sth like
>>>>>>> >
>>>>>>> > void foo (void)
>>>>>>> > __GIMPLE {
>>>>>>> > }
>>>>>>> >
>>>>>>> > as it's also kind-of a "definition" specifier rather than a
>>>>>>> > declaration specifier.
>>>>>>> >
>>>>>>> >>
>>>>>>> >> My intention is that we could reuse C FE for parsing types and decls
>>>>>>> >> (which I suppose is the primary
>>>>>>> >> motivation behind reusing C FE) and avoid mixing C statements with
>>>>>>> >> GIMPLE by having a separate
>>>>>>> >> GIMPLE parser for parsing GIMPLE functions.
>>>>>>> >> (I suppose the GIMPLE function parser would need to do minimal parsing
>>>>>>> >> of decls/types to recognize
>>>>>>> >> the input is a declaration and call C parsing routines for parsing the
>>>>>>> >> whole decl)
>>>>>>> >
>>>>>>> > Yes, eventually the C frontend provides routines that can be used
>>>>>>> > to tentatively parse declarations / types used in the function.
>>>>>>> >
>>>>>>> >> When C front-end is invoked with -fgimple it should probably only
>>>>>>> >> accept functions marked as "gimple".
>>>>>>> >> Does this sound reasonable ?
>>>>>>> >
>>>>>>> > I think -fgimple would only enable recognizing the __GIMPLE keyword,
>>>>>>> > I wouldn't change all defs to GIMPLE with it.
>>>>>>> >
>>>>>>> > Richard.
>>>>>>> >
>>>>>>> >> Thanks,
>>>>>>> >> Prathamesh
>>>>>>> >>>
>>>>>>> >>> In private discussion we somewhat agreed (Micha - correct me ;)) that
>>>>>>> >>> iff the GIMPLE FE would replace the C FE function body parsing
>>>>>>> >>> completely (re-using name lookup infrastructure of course) and iff the
>>>>>>> >>> GIMPLE FE would emit GIMPLE directly (just NULL DECL_SAVED_TREE
>>>>>>> >>> and a GIMPLE seq in DECL_STRUCT_FUNCTION->gimple_body)
>>>>>>> >>> then "re-using" the C FE would be a way to greatly speed up success.
>>>>>>> >>>
>>>>>>> >>> The other half of the project would then be to change the pass manager
>>>>>>> >>> to do something sensible with the produced GIMPLE as well as making
>>>>>>> >>> our dumps parseable by the GIMPLE FE.
>>>>>>> >>>
>>>>>>> >>> Richard.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Thanks and Regards,
>>>>>>> Prasad Ghangal
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thanks and Regards,
>>>>> Prasad Ghangal

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

[David Malcolm]

On Thu, 2016-03-24 at 14:31 +0100, Richard Biener wrote:
> On Thu, Mar 24, 2016 at 12:27 AM, Prasad Ghangal
> <prasad.ghangal@gmail.com> wrote:
> > Hi!
> > 
> > I have attached my gsoc proposal, please review it. Let me know if
> > I
> > have missed or misunderstood anything
> 
> Please re-word the Abstract, it is really weird to read - I suggest
> to drop
> any notion of RTL or "back end" and somehow mention that unit testing
> is why "we want make changes in GIMPLE".  Also stopping compilation
> isn't in the scope of the project (and while maybe a nice thing to
> have
> to do less work it is not a requirement for unit testing).
> 
> Thus Project Goals are only unit testing (which includes what you
> call
> start/stop compilation).
> 
> During the discussion in the last comments we agreed on re-using the
> C frontend for decls and types only and implement a completely
> separate
> parser for the function bodies so the frontend can also emit GIMPLE
> directly.
> 
> Thus I'd scrap 4.A)/B) and instead write about
> 
>   4.
>     A) Define GIMPLE syntax
>     Provide GIMPLE dumps with enough information to parse GIMPLE and
>     change them according to agreed on GIMPLE syntax
> 
>     B) Add __GIMPLE extension to the C FE and implement a GIMPLE
> parser
> 
> For the suggested timeline I think that it is important for the "get
> basic stuff working"
> part to have all pieces of the project prototyped, including the pass
> manager
> support.  Otherwise there is no way to fully test part of the
> implementation.
> I'd say modifying the gimple dumps can be done last as you can always
> write
> testcases manually.
> 
> I realize that the student application deadline is tomorrow.
> 
> Richard.

I like the overall idea, though I agree with Richard that the abstract
needs some rewording (as he writes above).

I think the key idea is to be able to "round-trip" any time in the
middle end where we're in the GIMPLE representation: save to a textual
format, and then to be able to load that format back in, and then run
from there, so that we can test the effect of specific passes on
specific fragments of GIMPLE.

I'd be willing to co-mentor you for this project with Richard.

However, I'm about to leave for the airport for a vacation (in a few hours), so the timing is rather bad. Sorry.  I will have only intermittent access to email until April 5th.

I have various ideas in this space, and I want to help with improving GCC's unit-testing.  FWIW, I've started experimenting with an *RTL* frontend, also for the purpose of unit-testing, in this case for the later parts of the compiler (so that we can unit-test e.g. the register allocators etc).  This could make a good "sister" project to the gimple frontend.  (There will be some things in common, and many differences).

Dave


> 
> 
> > 
> > Thanks and Regards,
> > Prasad Ghangal
> > 
> > 
> > 
> > 
> > 
> > On 22 March 2016 at 19:23, Richard Biener <
> > richard.guenther@gmail.com> wrote:
> > > On Tue, Mar 22, 2016 at 2:45 PM, Prathamesh Kulkarni
> > > <prathamesh.kulkarni@linaro.org> wrote:
> > > > On 22 March 2016 at 16:26, Richard Biener <
> > > > richard.guenther@gmail.com> wrote:
> > > > > On Tue, Mar 22, 2016 at 12:08 AM, Prasad Ghangal
> > > > > <prasad.ghangal@gmail.com> wrote:
> > > > > > Hi!
> > > > > > 
> > > > > > How exactly can we achieve start stop compilation on
> > > > > > specific pass (ie
> > > > > > run single pass on input)?
> > > > > > 
> > > > > > eg. $cgimple -ftree-copyrename foo.c
> > > > > > 
> > > > > > should produce optimization result of -ftree-copyrename
> > > > > > pass on foo.c input
> > > > > 
> > > > > You need pass manager support and annotate each function with
> > > > > information
> > > > > on what passes should be run (in which order even?).  I think
> > > > > for the GSoC
> > > > > project specifying a starting pass for each function via the
> > > > > source, like
> > > > > 
> > > > > __GIMPLE (tree-copyrename) void foo (void)
> > > > > {
> > > > > ...
> > > > > }
> > > > > 
> > > > > and hacking the pass manager to honor that is enough.
> > > > Um would annotating each function with pass order work for ipa
> > > > passes too ?
> > > 
> > > There is no single point of execution for an IPA pass so no - you
> > > can
> > > tag it with
> > > one of the umbrella passes I guess.  I suppose we'd need some
> > > magic "phase"
> > > tags for this, like simply "IPA".  You then need to
> > > enable/disable IPA passes
> > > you want to run.
> > > 
> > > Richard.
> > > 
> > > > Thanks,
> > > > Prathamesh
> > > > > 
> > > > > Richard.
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > On 21 March 2016 at 09:05, Trevor Saunders <
> > > > > > tbsaunde@tbsaunde.org> wrote:
> > > > > > > On Mon, Mar 21, 2016 at 04:43:35AM +0530, Prasad Ghangal
> > > > > > > wrote:
> > > > > > > > Hi!
> > > > > > > > 
> > > > > > > > Sorry for the late reply.
> > > > > > > > 
> > > > > > > > I was observing gimple dumps and my initial findings
> > > > > > > > are, to parse
> > > > > > > > gimple, we have to add support for following components
> > > > > > > > to C FE
> > > > > > > > 
> > > > > > > > *basic blocks
> > > > > > > 
> > > > > > > I'd think you can probably make these enough like C
> > > > > > > labels that you
> > > > > > > don't need to do anything special in the C fe to parse
> > > > > > > these.  Just
> > > > > > > removing the < and > gets you pretty close is that it?
> > > > > > > 
> > > > > > > > *gimple labels and goto
> > > > > > > 
> > > > > > > Similar I think.
> > > > > > > 
> > > > > > > > *gimple phi functions
> > > > > > > >         iftmp_0_1 = PHI (ftmp_0_3, iftmp_0_4)
> > > > > > > 
> > > > > > > yesI think you need to add something here.  I think you
> > > > > > > can do it as a
> > > > > > > builtin type function that expects its arguments to be
> > > > > > > labels or names
> > > > > > > of variables.
> > > > > > > 
> > > > > > > > *gimple switch
> > > > > > > >         switch (a_1) <default: <L0>, case 1: <L1>, case
> > > > > > > > 2: <L2>>
> > > > > > > 
> > > > > > > I'd think we could make this more C like too.
> > > > > > > 
> > > > > > > > *gimple exception handling
> > > > > > > 
> > > > > > > yeah, though note exceptions are lowered pretty quickly
> > > > > > > so supporting
> > > > > > > them with the explicit exception syntax probably isn't
> > > > > > > particularly
> > > > > > > important.
> > > > > > > 
> > > > > > > > *openmp functions like
> > > > > > > >         main._omp_fn.0 (void * .omp_data_i)
> > > > > > > 
> > > > > > > I'd think you'd want to change the duping of this some to
> > > > > > > make it easier
> > > > > > > to tell from struct.some.member.
> > > > > > > 
> > > > > > > > Please correct me if I am wrong. Also point out if I am
> > > > > > > > missing anything
> > > > > > > 
> > > > > > > I think you might need to do something about variable
> > > > > > > names?
> > > > > > > 
> > > > > > > Trev
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On 18 March 2016 at 14:53, Richard Biener <
> > > > > > > > richard.guenther@gmail.com> wrote:
> > > > > > > > > On Fri, Mar 18, 2016 at 6:55 AM, Prathamesh Kulkarni
> > > > > > > > > <prathamesh.kulkarni@linaro.org> wrote:
> > > > > > > > > > On 15 March 2016 at 20:46, Richard Biener <
> > > > > > > > > > richard.guenther@gmail.com> wrote:
> > > > > > > > > > > On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz <
> > > > > > > > > > > matz@suse.de> wrote:
> > > > > > > > > > > > Hi,
> > > > > > > > > > > > 
> > > > > > > > > > > > On Thu, 10 Mar 2016, Richard Biener wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > > 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).
> > > > > > > > > > > > 
> > > > > > > > > > > > I think it's wrong to try to shoehorn the
> > > > > > > > > > > > gimple FE into the C FE.  C is
> > > > > > > > > > > > fundamentally different from gimple and you'd
> > > > > > > > > > > > have to sprinkle
> > > > > > > > > > > > gimple_dialect_p() all over the place, and
> > > > > > > > > > > > maintaining that while
> > > > > > > > > > > > developing future C improvements will turn out
> > > > > > > > > > > > to be much work.  Some
> > > > > > > > > > > > differences of C and gimple:
> > > > > > > > > > > > 
> > > > > > > > > > > > * C has recursive expressions, gimple is n-op
> > > > > > > > > > > > stmts, no expressions at all
> > > > > > > > > > > > * C has type promotions, gimple is explicit
> > > > > > > > > > > > * C has all other kinds of automatic conversion
> > > > > > > > > > > > (e.g. pointer decay)
> > > > > > > > > > > > * C has scopes, gimple doesn't (well, global
> > > > > > > > > > > > and local only), i.e. symbol
> > > > > > > > > > > >   lookup is much more complicated
> > > > > > > > > > > > * C doesn't have exceptions
> > > > > > > > > > > > * C doesn't have class types, gimple has
> > > > > > > > > > > > * C doesn't have SSA (yes, I'm aware of your
> > > > > > > > > > > > suggestions for that)
> > > > > > > > > > > > * C doesn't have self-referential types
> > > > > > > > > > > > * C FE generates GENERIC, not GIMPLE (so you'd
> > > > > > > > > > > > need to go through the
> > > > > > > > > > > >   gimplifier and again would feed gimple
> > > > > > > > > > > > directly into the passes)
> > > > > > > > > > > > 
> > > > > > > > > > > > I really don't think changing the C FE to
> > > > > > > > > > > > accept gimple is a useful way
> > > > > > > > > > > > forward.
> > > > > > > > > > > 
> > > > > > > > > > > So I am most worried about replicating all the
> > > > > > > > > > > complexity of types and decl
> > > > > > > > > > > parsing for the presumably nice and small
> > > > > > > > > > > function body parser.
> > > > > > > > > > Um would it be a good idea if we separate "gimple"
> > > > > > > > > > functions from
> > > > > > > > > > regular C functions,
> > > > > > > > > > say by annotating the function definition with
> > > > > > > > > > "gimple" attribute ?
> > > > > > > > > 
> > > > > > > > > Yes, that was my idea.
> > > > > > > > > 
> > > > > > > > > > A "gimple" function should contain only gimple
> > > > > > > > > > stmts and not C.
> > > > > > > > > > eg:
> > > > > > > > > > __attribute__((gimple))
> > > > > > > > > > void foo(void)
> > > > > > > > > > {
> > > > > > > > > >   // local decls/initializers in C
> > > > > > > > > >   // GIMPLE body
> > > > > > > > > > }
> > > > > > > > > > Or perhaps we could add a new keyword "gimple"
> > > > > > > > > > telling C FE that this
> > > > > > > > > > is a GIMPLE function.
> > > > > > > > > 
> > > > > > > > > Though instead of an attribute I would indeed use a
> > > > > > > > > new keyword (as you
> > > > > > > > > can't really ignore the attribute and it should be an
> > > > > > > > > error with compilers
> > > > > > > > > not knowing it).  Thus sth like
> > > > > > > > > 
> > > > > > > > > void foo (void)
> > > > > > > > > __GIMPLE {
> > > > > > > > > }
> > > > > > > > > 
> > > > > > > > > as it's also kind-of a "definition" specifier rather
> > > > > > > > > than a
> > > > > > > > > declaration specifier.
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > My intention is that we could reuse C FE for
> > > > > > > > > > parsing types and decls
> > > > > > > > > > (which I suppose is the primary
> > > > > > > > > > motivation behind reusing C FE) and avoid mixing C
> > > > > > > > > > statements with
> > > > > > > > > > GIMPLE by having a separate
> > > > > > > > > > GIMPLE parser for parsing GIMPLE functions.
> > > > > > > > > > (I suppose the GIMPLE function parser would need to
> > > > > > > > > > do minimal parsing
> > > > > > > > > > of decls/types to recognize
> > > > > > > > > > the input is a declaration and call C parsing
> > > > > > > > > > routines for parsing the
> > > > > > > > > > whole decl)
> > > > > > > > > 
> > > > > > > > > Yes, eventually the C frontend provides routines that
> > > > > > > > > can be used
> > > > > > > > > to tentatively parse declarations / types used in the
> > > > > > > > > function.
> > > > > > > > > 
> > > > > > > > > > When C front-end is invoked with -fgimple it should
> > > > > > > > > > probably only
> > > > > > > > > > accept functions marked as "gimple".
> > > > > > > > > > Does this sound reasonable ?
> > > > > > > > > 
> > > > > > > > > I think -fgimple would only enable recognizing the
> > > > > > > > > __GIMPLE keyword,
> > > > > > > > > I wouldn't change all defs to GIMPLE with it.
> > > > > > > > > 
> > > > > > > > > Richard.
> > > > > > > > > 
> > > > > > > > > > Thanks,
> > > > > > > > > > Prathamesh
> > > > > > > > > > > 
> > > > > > > > > > > In private discussion we somewhat agreed (Micha -
> > > > > > > > > > > correct me ;)) that
> > > > > > > > > > > iff the GIMPLE FE would replace the C FE function
> > > > > > > > > > > body parsing
> > > > > > > > > > > completely (re-using name lookup infrastructure
> > > > > > > > > > > of course) and iff the
> > > > > > > > > > > GIMPLE FE would emit GIMPLE directly (just NULL
> > > > > > > > > > > DECL_SAVED_TREE
> > > > > > > > > > > and a GIMPLE seq in DECL_STRUCT_FUNCTION
> > > > > > > > > > > ->gimple_body)
> > > > > > > > > > > then "re-using" the C FE would be a way to
> > > > > > > > > > > greatly speed up success.
> > > > > > > > > > > 
> > > > > > > > > > > The other half of the project would then be to
> > > > > > > > > > > change the pass manager
> > > > > > > > > > > to do something sensible with the produced GIMPLE
> > > > > > > > > > > as well as making
> > > > > > > > > > > our dumps parseable by the GIMPLE FE.
> > > > > > > > > > > 
> > > > > > > > > > > Richard.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > --
> > > > > > > > Thanks and Regards,
> > > > > > > > Prasad Ghangal
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > --
> > > > > > Thanks and Regards,
> > > > > > Prasad Ghangal

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

[Richard Biener]

On March 24, 2016 6:30:29 PM GMT+01:00, David Malcolm <dmalcolm@redhat.com> wrote:
>On Thu, 2016-03-24 at 14:31 +0100, Richard Biener wrote:
>> On Thu, Mar 24, 2016 at 12:27 AM, Prasad Ghangal
>> <prasad.ghangal@gmail.com> wrote:
>> > Hi!
>> > 
>> > I have attached my gsoc proposal, please review it. Let me know if
>> > I
>> > have missed or misunderstood anything
>> 
>> Please re-word the Abstract, it is really weird to read - I suggest
>> to drop
>> any notion of RTL or "back end" and somehow mention that unit testing
>> is why "we want make changes in GIMPLE".  Also stopping compilation
>> isn't in the scope of the project (and while maybe a nice thing to
>> have
>> to do less work it is not a requirement for unit testing).
>> 
>> Thus Project Goals are only unit testing (which includes what you
>> call
>> start/stop compilation).
>> 
>> During the discussion in the last comments we agreed on re-using the
>> C frontend for decls and types only and implement a completely
>> separate
>> parser for the function bodies so the frontend can also emit GIMPLE
>> directly.
>> 
>> Thus I'd scrap 4.A)/B) and instead write about
>> 
>>   4.
>>     A) Define GIMPLE syntax
>>     Provide GIMPLE dumps with enough information to parse GIMPLE and
>>     change them according to agreed on GIMPLE syntax
>> 
>>     B) Add __GIMPLE extension to the C FE and implement a GIMPLE
>> parser
>> 
>> For the suggested timeline I think that it is important for the "get
>> basic stuff working"
>> part to have all pieces of the project prototyped, including the pass
>> manager
>> support.  Otherwise there is no way to fully test part of the
>> implementation.
>> I'd say modifying the gimple dumps can be done last as you can always
>> write
>> testcases manually.
>> 
>> I realize that the student application deadline is tomorrow.
>> 
>> Richard.
>
>I like the overall idea, though I agree with Richard that the abstract
>needs some rewording (as he writes above).
>
>I think the key idea is to be able to "round-trip" any time in the
>middle end where we're in the GIMPLE representation: save to a textual
>format, and then to be able to load that format back in, and then run
>from there, so that we can test the effect of specific passes on
>specific fragments of GIMPLE.
>
>I'd be willing to co-mentor you for this project with Richard.
>
>However, I'm about to leave for the airport for a vacation (in a few
>hours), so the timing is rather bad. Sorry.  I will have only
>intermittent access to email until April 5th.
>
>I have various ideas in this space, and I want to help with improving
>GCC's unit-testing.  FWIW, I've started experimenting with an *RTL*
>frontend, also for the purpose of unit-testing, in this case for the
>later parts of the compiler (so that we can unit-test e.g. the register
>allocators etc).  This could make a good "sister" project to the gimple
>frontend.  (There will be some things in common, and many differences).

I would expect many similarities but a __RTL keyword for The bodies.  Smaller scope might be possible if you dont need to go all the way to assembler generation.

Pass manager changes will be similar, though interesting side-effects with regard to any mandatory IL analysis we usually do not perform on RTL 

Richard.

>Dave
>
>
>> 
>> 
>> > 
>> > Thanks and Regards,
>> > Prasad Ghangal
>> > 
>> > 
>> > 
>> > 
>> > 
>> > On 22 March 2016 at 19:23, Richard Biener <
>> > richard.guenther@gmail.com> wrote:
>> > > On Tue, Mar 22, 2016 at 2:45 PM, Prathamesh Kulkarni
>> > > <prathamesh.kulkarni@linaro.org> wrote:
>> > > > On 22 March 2016 at 16:26, Richard Biener <
>> > > > richard.guenther@gmail.com> wrote:
>> > > > > On Tue, Mar 22, 2016 at 12:08 AM, Prasad Ghangal
>> > > > > <prasad.ghangal@gmail.com> wrote:
>> > > > > > Hi!
>> > > > > > 
>> > > > > > How exactly can we achieve start stop compilation on
>> > > > > > specific pass (ie
>> > > > > > run single pass on input)?
>> > > > > > 
>> > > > > > eg. $cgimple -ftree-copyrename foo.c
>> > > > > > 
>> > > > > > should produce optimization result of -ftree-copyrename
>> > > > > > pass on foo.c input
>> > > > > 
>> > > > > You need pass manager support and annotate each function with
>> > > > > information
>> > > > > on what passes should be run (in which order even?).  I think
>> > > > > for the GSoC
>> > > > > project specifying a starting pass for each function via the
>> > > > > source, like
>> > > > > 
>> > > > > __GIMPLE (tree-copyrename) void foo (void)
>> > > > > {
>> > > > > ...
>> > > > > }
>> > > > > 
>> > > > > and hacking the pass manager to honor that is enough.
>> > > > Um would annotating each function with pass order work for ipa
>> > > > passes too ?
>> > > 
>> > > There is no single point of execution for an IPA pass so no - you
>> > > can
>> > > tag it with
>> > > one of the umbrella passes I guess.  I suppose we'd need some
>> > > magic "phase"
>> > > tags for this, like simply "IPA".  You then need to
>> > > enable/disable IPA passes
>> > > you want to run.
>> > > 
>> > > Richard.
>> > > 
>> > > > Thanks,
>> > > > Prathamesh
>> > > > > 
>> > > > > Richard.
>> > > > > 
>> > > > > > 
>> > > > > > 
>> > > > > > On 21 March 2016 at 09:05, Trevor Saunders <
>> > > > > > tbsaunde@tbsaunde.org> wrote:
>> > > > > > > On Mon, Mar 21, 2016 at 04:43:35AM +0530, Prasad Ghangal
>> > > > > > > wrote:
>> > > > > > > > Hi!
>> > > > > > > > 
>> > > > > > > > Sorry for the late reply.
>> > > > > > > > 
>> > > > > > > > I was observing gimple dumps and my initial findings
>> > > > > > > > are, to parse
>> > > > > > > > gimple, we have to add support for following components
>> > > > > > > > to C FE
>> > > > > > > > 
>> > > > > > > > *basic blocks
>> > > > > > > 
>> > > > > > > I'd think you can probably make these enough like C
>> > > > > > > labels that you
>> > > > > > > don't need to do anything special in the C fe to parse
>> > > > > > > these.  Just
>> > > > > > > removing the < and > gets you pretty close is that it?
>> > > > > > > 
>> > > > > > > > *gimple labels and goto
>> > > > > > > 
>> > > > > > > Similar I think.
>> > > > > > > 
>> > > > > > > > *gimple phi functions
>> > > > > > > >         iftmp_0_1 = PHI (ftmp_0_3, iftmp_0_4)
>> > > > > > > 
>> > > > > > > yesI think you need to add something here.  I think you
>> > > > > > > can do it as a
>> > > > > > > builtin type function that expects its arguments to be
>> > > > > > > labels or names
>> > > > > > > of variables.
>> > > > > > > 
>> > > > > > > > *gimple switch
>> > > > > > > >         switch (a_1) <default: <L0>, case 1: <L1>, case
>> > > > > > > > 2: <L2>>
>> > > > > > > 
>> > > > > > > I'd think we could make this more C like too.
>> > > > > > > 
>> > > > > > > > *gimple exception handling
>> > > > > > > 
>> > > > > > > yeah, though note exceptions are lowered pretty quickly
>> > > > > > > so supporting
>> > > > > > > them with the explicit exception syntax probably isn't
>> > > > > > > particularly
>> > > > > > > important.
>> > > > > > > 
>> > > > > > > > *openmp functions like
>> > > > > > > >         main._omp_fn.0 (void * .omp_data_i)
>> > > > > > > 
>> > > > > > > I'd think you'd want to change the duping of this some to
>> > > > > > > make it easier
>> > > > > > > to tell from struct.some.member.
>> > > > > > > 
>> > > > > > > > Please correct me if I am wrong. Also point out if I am
>> > > > > > > > missing anything
>> > > > > > > 
>> > > > > > > I think you might need to do something about variable
>> > > > > > > names?
>> > > > > > > 
>> > > > > > > Trev
>> > > > > > > 
>> > > > > > > > 
>> > > > > > > > 
>> > > > > > > > 
>> > > > > > > > 
>> > > > > > > > On 18 March 2016 at 14:53, Richard Biener <
>> > > > > > > > richard.guenther@gmail.com> wrote:
>> > > > > > > > > On Fri, Mar 18, 2016 at 6:55 AM, Prathamesh Kulkarni
>> > > > > > > > > <prathamesh.kulkarni@linaro.org> wrote:
>> > > > > > > > > > On 15 March 2016 at 20:46, Richard Biener <
>> > > > > > > > > > richard.guenther@gmail.com> wrote:
>> > > > > > > > > > > On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz <
>> > > > > > > > > > > matz@suse.de> wrote:
>> > > > > > > > > > > > Hi,
>> > > > > > > > > > > > 
>> > > > > > > > > > > > On Thu, 10 Mar 2016, Richard Biener wrote:
>> > > > > > > > > > > > 
>> > > > > > > > > > > > > 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).
>> > > > > > > > > > > > 
>> > > > > > > > > > > > I think it's wrong to try to shoehorn the
>> > > > > > > > > > > > gimple FE into the C FE.  C is
>> > > > > > > > > > > > fundamentally different from gimple and you'd
>> > > > > > > > > > > > have to sprinkle
>> > > > > > > > > > > > gimple_dialect_p() all over the place, and
>> > > > > > > > > > > > maintaining that while
>> > > > > > > > > > > > developing future C improvements will turn out
>> > > > > > > > > > > > to be much work.  Some
>> > > > > > > > > > > > differences of C and gimple:
>> > > > > > > > > > > > 
>> > > > > > > > > > > > * C has recursive expressions, gimple is n-op
>> > > > > > > > > > > > stmts, no expressions at all
>> > > > > > > > > > > > * C has type promotions, gimple is explicit
>> > > > > > > > > > > > * C has all other kinds of automatic conversion
>> > > > > > > > > > > > (e.g. pointer decay)
>> > > > > > > > > > > > * C has scopes, gimple doesn't (well, global
>> > > > > > > > > > > > and local only), i.e. symbol
>> > > > > > > > > > > >   lookup is much more complicated
>> > > > > > > > > > > > * C doesn't have exceptions
>> > > > > > > > > > > > * C doesn't have class types, gimple has
>> > > > > > > > > > > > * C doesn't have SSA (yes, I'm aware of your
>> > > > > > > > > > > > suggestions for that)
>> > > > > > > > > > > > * C doesn't have self-referential types
>> > > > > > > > > > > > * C FE generates GENERIC, not GIMPLE (so you'd
>> > > > > > > > > > > > need to go through the
>> > > > > > > > > > > >   gimplifier and again would feed gimple
>> > > > > > > > > > > > directly into the passes)
>> > > > > > > > > > > > 
>> > > > > > > > > > > > I really don't think changing the C FE to
>> > > > > > > > > > > > accept gimple is a useful way
>> > > > > > > > > > > > forward.
>> > > > > > > > > > > 
>> > > > > > > > > > > So I am most worried about replicating all the
>> > > > > > > > > > > complexity of types and decl
>> > > > > > > > > > > parsing for the presumably nice and small
>> > > > > > > > > > > function body parser.
>> > > > > > > > > > Um would it be a good idea if we separate "gimple"
>> > > > > > > > > > functions from
>> > > > > > > > > > regular C functions,
>> > > > > > > > > > say by annotating the function definition with
>> > > > > > > > > > "gimple" attribute ?
>> > > > > > > > > 
>> > > > > > > > > Yes, that was my idea.
>> > > > > > > > > 
>> > > > > > > > > > A "gimple" function should contain only gimple
>> > > > > > > > > > stmts and not C.
>> > > > > > > > > > eg:
>> > > > > > > > > > __attribute__((gimple))
>> > > > > > > > > > void foo(void)
>> > > > > > > > > > {
>> > > > > > > > > >   // local decls/initializers in C
>> > > > > > > > > >   // GIMPLE body
>> > > > > > > > > > }
>> > > > > > > > > > Or perhaps we could add a new keyword "gimple"
>> > > > > > > > > > telling C FE that this
>> > > > > > > > > > is a GIMPLE function.
>> > > > > > > > > 
>> > > > > > > > > Though instead of an attribute I would indeed use a
>> > > > > > > > > new keyword (as you
>> > > > > > > > > can't really ignore the attribute and it should be an
>> > > > > > > > > error with compilers
>> > > > > > > > > not knowing it).  Thus sth like
>> > > > > > > > > 
>> > > > > > > > > void foo (void)
>> > > > > > > > > __GIMPLE {
>> > > > > > > > > }
>> > > > > > > > > 
>> > > > > > > > > as it's also kind-of a "definition" specifier rather
>> > > > > > > > > than a
>> > > > > > > > > declaration specifier.
>> > > > > > > > > 
>> > > > > > > > > > 
>> > > > > > > > > > My intention is that we could reuse C FE for
>> > > > > > > > > > parsing types and decls
>> > > > > > > > > > (which I suppose is the primary
>> > > > > > > > > > motivation behind reusing C FE) and avoid mixing C
>> > > > > > > > > > statements with
>> > > > > > > > > > GIMPLE by having a separate
>> > > > > > > > > > GIMPLE parser for parsing GIMPLE functions.
>> > > > > > > > > > (I suppose the GIMPLE function parser would need to
>> > > > > > > > > > do minimal parsing
>> > > > > > > > > > of decls/types to recognize
>> > > > > > > > > > the input is a declaration and call C parsing
>> > > > > > > > > > routines for parsing the
>> > > > > > > > > > whole decl)
>> > > > > > > > > 
>> > > > > > > > > Yes, eventually the C frontend provides routines that
>> > > > > > > > > can be used
>> > > > > > > > > to tentatively parse declarations / types used in the
>> > > > > > > > > function.
>> > > > > > > > > 
>> > > > > > > > > > When C front-end is invoked with -fgimple it should
>> > > > > > > > > > probably only
>> > > > > > > > > > accept functions marked as "gimple".
>> > > > > > > > > > Does this sound reasonable ?
>> > > > > > > > > 
>> > > > > > > > > I think -fgimple would only enable recognizing the
>> > > > > > > > > __GIMPLE keyword,
>> > > > > > > > > I wouldn't change all defs to GIMPLE with it.
>> > > > > > > > > 
>> > > > > > > > > Richard.
>> > > > > > > > > 
>> > > > > > > > > > Thanks,
>> > > > > > > > > > Prathamesh
>> > > > > > > > > > > 
>> > > > > > > > > > > In private discussion we somewhat agreed (Micha -
>> > > > > > > > > > > correct me ;)) that
>> > > > > > > > > > > iff the GIMPLE FE would replace the C FE function
>> > > > > > > > > > > body parsing
>> > > > > > > > > > > completely (re-using name lookup infrastructure
>> > > > > > > > > > > of course) and iff the
>> > > > > > > > > > > GIMPLE FE would emit GIMPLE directly (just NULL
>> > > > > > > > > > > DECL_SAVED_TREE
>> > > > > > > > > > > and a GIMPLE seq in DECL_STRUCT_FUNCTION
>> > > > > > > > > > > ->gimple_body)
>> > > > > > > > > > > then "re-using" the C FE would be a way to
>> > > > > > > > > > > greatly speed up success.
>> > > > > > > > > > > 
>> > > > > > > > > > > The other half of the project would then be to
>> > > > > > > > > > > change the pass manager
>> > > > > > > > > > > to do something sensible with the produced GIMPLE
>> > > > > > > > > > > as well as making
>> > > > > > > > > > > our dumps parseable by the GIMPLE FE.
>> > > > > > > > > > > 
>> > > > > > > > > > > Richard.
>> > > > > > > > 
>> > > > > > > > 
>> > > > > > > > 
>> > > > > > > > --
>> > > > > > > > Thanks and Regards,
>> > > > > > > > Prasad Ghangal
>> > > > > > 
>> > > > > > 
>> > > > > > 
>> > > > > > --
>> > > > > > Thanks and Regards,
>> > > > > > Prasad Ghangal

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

[Prasad Ghangal]

On 24 March 2016 at 19:01, Richard Biener <richard.guenther@gmail.com> wrote:
> On Thu, Mar 24, 2016 at 12:27 AM, Prasad Ghangal
> <prasad.ghangal@gmail.com> wrote:
>> Hi!
>>
>> I have attached my gsoc proposal, please review it. Let me know if I
>> have missed or misunderstood anything
>
> Please re-word the Abstract, it is really weird to read - I suggest to drop
> any notion of RTL or "back end" and somehow mention that unit testing
> is why "we want make changes in GIMPLE".  Also stopping compilation
> isn't in the scope of the project (and while maybe a nice thing to have
> to do less work it is not a requirement for unit testing).
>
> Thus Project Goals are only unit testing (which includes what you call
> start/stop compilation).
>
> During the discussion in the last comments we agreed on re-using the
> C frontend for decls and types only and implement a completely separate
> parser for the function bodies so the frontend can also emit GIMPLE directly.
>
> Thus I'd scrap 4.A)/B) and instead write about
>
>   4.
>     A) Define GIMPLE syntax
>     Provide GIMPLE dumps with enough information to parse GIMPLE and
>     change them according to agreed on GIMPLE syntax

Little confused here. Don't we need to change syntax first and then
develop grammar to parse it?

>
>     B) Add __GIMPLE extension to the C FE and implement a GIMPLE parser
>
> For the suggested timeline I think that it is important for the "get
> basic stuff working"
> part to have all pieces of the project prototyped, including the pass manager
> support.  Otherwise there is no way to fully test part of the implementation.
> I'd say modifying the gimple dumps can be done last as you can always write
> testcases manually.
>
> I realize that the student application deadline is tomorrow.
>
> Richard.
>
>
>
>>
>> Thanks and Regards,
>> Prasad Ghangal
>>
>>
>>
>>
>>
>> On 22 March 2016 at 19:23, Richard Biener <richard.guenther@gmail.com> wrote:
>>> On Tue, Mar 22, 2016 at 2:45 PM, Prathamesh Kulkarni
>>> <prathamesh.kulkarni@linaro.org> wrote:
>>>> On 22 March 2016 at 16:26, Richard Biener <richard.guenther@gmail.com> wrote:
>>>>> On Tue, Mar 22, 2016 at 12:08 AM, Prasad Ghangal
>>>>> <prasad.ghangal@gmail.com> wrote:
>>>>>> Hi!
>>>>>>
>>>>>> How exactly can we achieve start stop compilation on specific pass (ie
>>>>>> run single pass on input)?
>>>>>>
>>>>>> eg. $cgimple -ftree-copyrename foo.c
>>>>>>
>>>>>> should produce optimization result of -ftree-copyrename pass on foo.c input
>>>>>
>>>>> You need pass manager support and annotate each function with information
>>>>> on what passes should be run (in which order even?).  I think for the GSoC
>>>>> project specifying a starting pass for each function via the source, like
>>>>>
>>>>> __GIMPLE (tree-copyrename) void foo (void)
>>>>> {
>>>>> ...
>>>>> }
>>>>>
>>>>> and hacking the pass manager to honor that is enough.
>>>> Um would annotating each function with pass order work for ipa passes too ?
>>>
>>> There is no single point of execution for an IPA pass so no - you can
>>> tag it with
>>> one of the umbrella passes I guess.  I suppose we'd need some magic "phase"
>>> tags for this, like simply "IPA".  You then need to enable/disable IPA passes
>>> you want to run.
>>>
>>> Richard.
>>>
>>>> Thanks,
>>>> Prathamesh
>>>>>
>>>>> Richard.
>>>>>
>>>>>>
>>>>>>
>>>>>> On 21 March 2016 at 09:05, Trevor Saunders <tbsaunde@tbsaunde.org> wrote:
>>>>>>> On Mon, Mar 21, 2016 at 04:43:35AM +0530, Prasad Ghangal wrote:
>>>>>>>> Hi!
>>>>>>>>
>>>>>>>> Sorry for the late reply.
>>>>>>>>
>>>>>>>> I was observing gimple dumps and my initial findings are, to parse
>>>>>>>> gimple, we have to add support for following components to C FE
>>>>>>>>
>>>>>>>> *basic blocks
>>>>>>>
>>>>>>> I'd think you can probably make these enough like C labels that you
>>>>>>> don't need to do anything special in the C fe to parse these.  Just
>>>>>>> removing the < and > gets you pretty close is that it?
>>>>>>>
>>>>>>>> *gimple labels and goto
>>>>>>>
>>>>>>> Similar I think.
>>>>>>>
>>>>>>>> *gimple phi functions
>>>>>>>>         iftmp_0_1 = PHI (ftmp_0_3, iftmp_0_4)
>>>>>>>
>>>>>>> yesI think you need to add something here.  I think you can do it as a
>>>>>>> builtin type function that expects its arguments to be labels or names
>>>>>>> of variables.
>>>>>>>
>>>>>>>> *gimple switch
>>>>>>>>         switch (a_1) <default: <L0>, case 1: <L1>, case 2: <L2>>
>>>>>>>
>>>>>>> I'd think we could make this more C like too.
>>>>>>>
>>>>>>>> *gimple exception handling
>>>>>>>
>>>>>>> yeah, though note exceptions are lowered pretty quickly so supporting
>>>>>>> them with the explicit exception syntax probably isn't particularly
>>>>>>> important.
>>>>>>>
>>>>>>>> *openmp functions like
>>>>>>>>         main._omp_fn.0 (void * .omp_data_i)
>>>>>>>
>>>>>>> I'd think you'd want to change the duping of this some to make it easier
>>>>>>> to tell from struct.some.member.
>>>>>>>
>>>>>>>> Please correct me if I am wrong. Also point out if I am missing anything
>>>>>>>
>>>>>>> I think you might need to do something about variable names?
>>>>>>>
>>>>>>> Trev
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 18 March 2016 at 14:53, Richard Biener <richard.guenther@gmail.com> wrote:
>>>>>>>> > On Fri, Mar 18, 2016 at 6:55 AM, Prathamesh Kulkarni
>>>>>>>> > <prathamesh.kulkarni@linaro.org> wrote:
>>>>>>>> >> On 15 March 2016 at 20:46, Richard Biener <richard.guenther@gmail.com> wrote:
>>>>>>>> >>> On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz <matz@suse.de> wrote:
>>>>>>>> >>>> Hi,
>>>>>>>> >>>>
>>>>>>>> >>>> On Thu, 10 Mar 2016, Richard Biener wrote:
>>>>>>>> >>>>
>>>>>>>> >>>>> 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).
>>>>>>>> >>>>
>>>>>>>> >>>> I think it's wrong to try to shoehorn the gimple FE into the C FE.  C is
>>>>>>>> >>>> fundamentally different from gimple and you'd have to sprinkle
>>>>>>>> >>>> gimple_dialect_p() all over the place, and maintaining that while
>>>>>>>> >>>> developing future C improvements will turn out to be much work.  Some
>>>>>>>> >>>> differences of C and gimple:
>>>>>>>> >>>>
>>>>>>>> >>>> * C has recursive expressions, gimple is n-op stmts, no expressions at all
>>>>>>>> >>>> * C has type promotions, gimple is explicit
>>>>>>>> >>>> * C has all other kinds of automatic conversion (e.g. pointer decay)
>>>>>>>> >>>> * C has scopes, gimple doesn't (well, global and local only), i.e. symbol
>>>>>>>> >>>>   lookup is much more complicated
>>>>>>>> >>>> * C doesn't have exceptions
>>>>>>>> >>>> * C doesn't have class types, gimple has
>>>>>>>> >>>> * C doesn't have SSA (yes, I'm aware of your suggestions for that)
>>>>>>>> >>>> * C doesn't have self-referential types
>>>>>>>> >>>> * C FE generates GENERIC, not GIMPLE (so you'd need to go through the
>>>>>>>> >>>>   gimplifier and again would feed gimple directly into the passes)
>>>>>>>> >>>>
>>>>>>>> >>>> I really don't think changing the C FE to accept gimple is a useful way
>>>>>>>> >>>> forward.
>>>>>>>> >>>
>>>>>>>> >>> So I am most worried about replicating all the complexity of types and decl
>>>>>>>> >>> parsing for the presumably nice and small function body parser.
>>>>>>>> >> Um would it be a good idea if we separate "gimple" functions from
>>>>>>>> >> regular C functions,
>>>>>>>> >> say by annotating the function definition with "gimple" attribute ?
>>>>>>>> >
>>>>>>>> > Yes, that was my idea.
>>>>>>>> >
>>>>>>>> >> A "gimple" function should contain only gimple stmts and not C.
>>>>>>>> >> eg:
>>>>>>>> >> __attribute__((gimple))
>>>>>>>> >> void foo(void)
>>>>>>>> >> {
>>>>>>>> >>   // local decls/initializers in C
>>>>>>>> >>   // GIMPLE body
>>>>>>>> >> }
>>>>>>>> >> Or perhaps we could add a new keyword "gimple" telling C FE that this
>>>>>>>> >> is a GIMPLE function.
>>>>>>>> >
>>>>>>>> > Though instead of an attribute I would indeed use a new keyword (as you
>>>>>>>> > can't really ignore the attribute and it should be an error with compilers
>>>>>>>> > not knowing it).  Thus sth like
>>>>>>>> >
>>>>>>>> > void foo (void)
>>>>>>>> > __GIMPLE {
>>>>>>>> > }
>>>>>>>> >
>>>>>>>> > as it's also kind-of a "definition" specifier rather than a
>>>>>>>> > declaration specifier.
>>>>>>>> >
>>>>>>>> >>
>>>>>>>> >> My intention is that we could reuse C FE for parsing types and decls
>>>>>>>> >> (which I suppose is the primary
>>>>>>>> >> motivation behind reusing C FE) and avoid mixing C statements with
>>>>>>>> >> GIMPLE by having a separate
>>>>>>>> >> GIMPLE parser for parsing GIMPLE functions.
>>>>>>>> >> (I suppose the GIMPLE function parser would need to do minimal parsing
>>>>>>>> >> of decls/types to recognize
>>>>>>>> >> the input is a declaration and call C parsing routines for parsing the
>>>>>>>> >> whole decl)
>>>>>>>> >
>>>>>>>> > Yes, eventually the C frontend provides routines that can be used
>>>>>>>> > to tentatively parse declarations / types used in the function.
>>>>>>>> >
>>>>>>>> >> When C front-end is invoked with -fgimple it should probably only
>>>>>>>> >> accept functions marked as "gimple".
>>>>>>>> >> Does this sound reasonable ?
>>>>>>>> >
>>>>>>>> > I think -fgimple would only enable recognizing the __GIMPLE keyword,
>>>>>>>> > I wouldn't change all defs to GIMPLE with it.
>>>>>>>> >
>>>>>>>> > Richard.
>>>>>>>> >
>>>>>>>> >> Thanks,
>>>>>>>> >> Prathamesh
>>>>>>>> >>>
>>>>>>>> >>> In private discussion we somewhat agreed (Micha - correct me ;)) that
>>>>>>>> >>> iff the GIMPLE FE would replace the C FE function body parsing
>>>>>>>> >>> completely (re-using name lookup infrastructure of course) and iff the
>>>>>>>> >>> GIMPLE FE would emit GIMPLE directly (just NULL DECL_SAVED_TREE
>>>>>>>> >>> and a GIMPLE seq in DECL_STRUCT_FUNCTION->gimple_body)
>>>>>>>> >>> then "re-using" the C FE would be a way to greatly speed up success.
>>>>>>>> >>>
>>>>>>>> >>> The other half of the project would then be to change the pass manager
>>>>>>>> >>> to do something sensible with the produced GIMPLE as well as making
>>>>>>>> >>> our dumps parseable by the GIMPLE FE.
>>>>>>>> >>>
>>>>>>>> >>> Richard.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Thanks and Regards,
>>>>>>>> Prasad Ghangal
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Thanks and Regards,
>>>>>> Prasad Ghangal

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

[Prathamesh Kulkarni]

On 25 March 2016 at 01:15, Prasad Ghangal <prasad.ghangal@gmail.com> wrote:
> On 24 March 2016 at 19:01, Richard Biener <richard.guenther@gmail.com> wrote:
>> On Thu, Mar 24, 2016 at 12:27 AM, Prasad Ghangal
>> <prasad.ghangal@gmail.com> wrote:
>>> Hi!
>>>
>>> I have attached my gsoc proposal, please review it. Let me know if I
>>> have missed or misunderstood anything
>>
>> Please re-word the Abstract, it is really weird to read - I suggest to drop
>> any notion of RTL or "back end" and somehow mention that unit testing
>> is why "we want make changes in GIMPLE".  Also stopping compilation
>> isn't in the scope of the project (and while maybe a nice thing to have
>> to do less work it is not a requirement for unit testing).
>>
>> Thus Project Goals are only unit testing (which includes what you call
>> start/stop compilation).
>>
>> During the discussion in the last comments we agreed on re-using the
>> C frontend for decls and types only and implement a completely separate
>> parser for the function bodies so the frontend can also emit GIMPLE directly.
>>
>> Thus I'd scrap 4.A)/B) and instead write about
>>
>>   4.
>>     A) Define GIMPLE syntax
>>     Provide GIMPLE dumps with enough information to parse GIMPLE and
>>     change them according to agreed on GIMPLE syntax
>
> Little confused here. Don't we need to change syntax first and then
> develop grammar to parse it?
Well the purpose of grammar is to define the syntax.
We would need to first define a grammar for GIMPLE and then implement
a (predictive) parser
that parses GIMPLE input according to our grammar and emits GIMPLE IR.
contrived eg:
stmt_list: stmt stmt_list_1
stmt_list_1: stmt stmt_list_1 | epsilon
stmt:  lvalue_operand '=' assign_stmt
      |   'if' cond_stmt
assign_stmt:  operand | operator operand | operand operator operand
operand:  INT | lvalue_operand
lvalue_operand: ID
operator: '+'

As pointed out by Richard, dumps could be modified later to adjust to
GIMPLE syntax,
initially you could write test-cases by hand.

Thanks,
Prathamesh
>
>>
>>     B) Add __GIMPLE extension to the C FE and implement a GIMPLE parser
>>
>> For the suggested timeline I think that it is important for the "get
>> basic stuff working"
>> part to have all pieces of the project prototyped, including the pass manager
>> support.  Otherwise there is no way to fully test part of the implementation.
>> I'd say modifying the gimple dumps can be done last as you can always write
>> testcases manually.
>>
>> I realize that the student application deadline is tomorrow.
>>
>> Richard.
>>
>>
>>
>>>
>>> Thanks and Regards,
>>> Prasad Ghangal
>>>
>>>
>>>
>>>
>>>
>>> On 22 March 2016 at 19:23, Richard Biener <richard.guenther@gmail.com> wrote:
>>>> On Tue, Mar 22, 2016 at 2:45 PM, Prathamesh Kulkarni
>>>> <prathamesh.kulkarni@linaro.org> wrote:
>>>>> On 22 March 2016 at 16:26, Richard Biener <richard.guenther@gmail.com> wrote:
>>>>>> On Tue, Mar 22, 2016 at 12:08 AM, Prasad Ghangal
>>>>>> <prasad.ghangal@gmail.com> wrote:
>>>>>>> Hi!
>>>>>>>
>>>>>>> How exactly can we achieve start stop compilation on specific pass (ie
>>>>>>> run single pass on input)?
>>>>>>>
>>>>>>> eg. $cgimple -ftree-copyrename foo.c
>>>>>>>
>>>>>>> should produce optimization result of -ftree-copyrename pass on foo.c input
>>>>>>
>>>>>> You need pass manager support and annotate each function with information
>>>>>> on what passes should be run (in which order even?).  I think for the GSoC
>>>>>> project specifying a starting pass for each function via the source, like
>>>>>>
>>>>>> __GIMPLE (tree-copyrename) void foo (void)
>>>>>> {
>>>>>> ...
>>>>>> }
>>>>>>
>>>>>> and hacking the pass manager to honor that is enough.
>>>>> Um would annotating each function with pass order work for ipa passes too ?
>>>>
>>>> There is no single point of execution for an IPA pass so no - you can
>>>> tag it with
>>>> one of the umbrella passes I guess.  I suppose we'd need some magic "phase"
>>>> tags for this, like simply "IPA".  You then need to enable/disable IPA passes
>>>> you want to run.
>>>>
>>>> Richard.
>>>>
>>>>> Thanks,
>>>>> Prathamesh
>>>>>>
>>>>>> Richard.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 21 March 2016 at 09:05, Trevor Saunders <tbsaunde@tbsaunde.org> wrote:
>>>>>>>> On Mon, Mar 21, 2016 at 04:43:35AM +0530, Prasad Ghangal wrote:
>>>>>>>>> Hi!
>>>>>>>>>
>>>>>>>>> Sorry for the late reply.
>>>>>>>>>
>>>>>>>>> I was observing gimple dumps and my initial findings are, to parse
>>>>>>>>> gimple, we have to add support for following components to C FE
>>>>>>>>>
>>>>>>>>> *basic blocks
>>>>>>>>
>>>>>>>> I'd think you can probably make these enough like C labels that you
>>>>>>>> don't need to do anything special in the C fe to parse these.  Just
>>>>>>>> removing the < and > gets you pretty close is that it?
>>>>>>>>
>>>>>>>>> *gimple labels and goto
>>>>>>>>
>>>>>>>> Similar I think.
>>>>>>>>
>>>>>>>>> *gimple phi functions
>>>>>>>>>         iftmp_0_1 = PHI (ftmp_0_3, iftmp_0_4)
>>>>>>>>
>>>>>>>> yesI think you need to add something here.  I think you can do it as a
>>>>>>>> builtin type function that expects its arguments to be labels or names
>>>>>>>> of variables.
>>>>>>>>
>>>>>>>>> *gimple switch
>>>>>>>>>         switch (a_1) <default: <L0>, case 1: <L1>, case 2: <L2>>
>>>>>>>>
>>>>>>>> I'd think we could make this more C like too.
>>>>>>>>
>>>>>>>>> *gimple exception handling
>>>>>>>>
>>>>>>>> yeah, though note exceptions are lowered pretty quickly so supporting
>>>>>>>> them with the explicit exception syntax probably isn't particularly
>>>>>>>> important.
>>>>>>>>
>>>>>>>>> *openmp functions like
>>>>>>>>>         main._omp_fn.0 (void * .omp_data_i)
>>>>>>>>
>>>>>>>> I'd think you'd want to change the duping of this some to make it easier
>>>>>>>> to tell from struct.some.member.
>>>>>>>>
>>>>>>>>> Please correct me if I am wrong. Also point out if I am missing anything
>>>>>>>>
>>>>>>>> I think you might need to do something about variable names?
>>>>>>>>
>>>>>>>> Trev
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 18 March 2016 at 14:53, Richard Biener <richard.guenther@gmail.com> wrote:
>>>>>>>>> > On Fri, Mar 18, 2016 at 6:55 AM, Prathamesh Kulkarni
>>>>>>>>> > <prathamesh.kulkarni@linaro.org> wrote:
>>>>>>>>> >> On 15 March 2016 at 20:46, Richard Biener <richard.guenther@gmail.com> wrote:
>>>>>>>>> >>> On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz <matz@suse.de> wrote:
>>>>>>>>> >>>> Hi,
>>>>>>>>> >>>>
>>>>>>>>> >>>> On Thu, 10 Mar 2016, Richard Biener wrote:
>>>>>>>>> >>>>
>>>>>>>>> >>>>> 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).
>>>>>>>>> >>>>
>>>>>>>>> >>>> I think it's wrong to try to shoehorn the gimple FE into the C FE.  C is
>>>>>>>>> >>>> fundamentally different from gimple and you'd have to sprinkle
>>>>>>>>> >>>> gimple_dialect_p() all over the place, and maintaining that while
>>>>>>>>> >>>> developing future C improvements will turn out to be much work.  Some
>>>>>>>>> >>>> differences of C and gimple:
>>>>>>>>> >>>>
>>>>>>>>> >>>> * C has recursive expressions, gimple is n-op stmts, no expressions at all
>>>>>>>>> >>>> * C has type promotions, gimple is explicit
>>>>>>>>> >>>> * C has all other kinds of automatic conversion (e.g. pointer decay)
>>>>>>>>> >>>> * C has scopes, gimple doesn't (well, global and local only), i.e. symbol
>>>>>>>>> >>>>   lookup is much more complicated
>>>>>>>>> >>>> * C doesn't have exceptions
>>>>>>>>> >>>> * C doesn't have class types, gimple has
>>>>>>>>> >>>> * C doesn't have SSA (yes, I'm aware of your suggestions for that)
>>>>>>>>> >>>> * C doesn't have self-referential types
>>>>>>>>> >>>> * C FE generates GENERIC, not GIMPLE (so you'd need to go through the
>>>>>>>>> >>>>   gimplifier and again would feed gimple directly into the passes)
>>>>>>>>> >>>>
>>>>>>>>> >>>> I really don't think changing the C FE to accept gimple is a useful way
>>>>>>>>> >>>> forward.
>>>>>>>>> >>>
>>>>>>>>> >>> So I am most worried about replicating all the complexity of types and decl
>>>>>>>>> >>> parsing for the presumably nice and small function body parser.
>>>>>>>>> >> Um would it be a good idea if we separate "gimple" functions from
>>>>>>>>> >> regular C functions,
>>>>>>>>> >> say by annotating the function definition with "gimple" attribute ?
>>>>>>>>> >
>>>>>>>>> > Yes, that was my idea.
>>>>>>>>> >
>>>>>>>>> >> A "gimple" function should contain only gimple stmts and not C.
>>>>>>>>> >> eg:
>>>>>>>>> >> __attribute__((gimple))
>>>>>>>>> >> void foo(void)
>>>>>>>>> >> {
>>>>>>>>> >>   // local decls/initializers in C
>>>>>>>>> >>   // GIMPLE body
>>>>>>>>> >> }
>>>>>>>>> >> Or perhaps we could add a new keyword "gimple" telling C FE that this
>>>>>>>>> >> is a GIMPLE function.
>>>>>>>>> >
>>>>>>>>> > Though instead of an attribute I would indeed use a new keyword (as you
>>>>>>>>> > can't really ignore the attribute and it should be an error with compilers
>>>>>>>>> > not knowing it).  Thus sth like
>>>>>>>>> >
>>>>>>>>> > void foo (void)
>>>>>>>>> > __GIMPLE {
>>>>>>>>> > }
>>>>>>>>> >
>>>>>>>>> > as it's also kind-of a "definition" specifier rather than a
>>>>>>>>> > declaration specifier.
>>>>>>>>> >
>>>>>>>>> >>
>>>>>>>>> >> My intention is that we could reuse C FE for parsing types and decls
>>>>>>>>> >> (which I suppose is the primary
>>>>>>>>> >> motivation behind reusing C FE) and avoid mixing C statements with
>>>>>>>>> >> GIMPLE by having a separate
>>>>>>>>> >> GIMPLE parser for parsing GIMPLE functions.
>>>>>>>>> >> (I suppose the GIMPLE function parser would need to do minimal parsing
>>>>>>>>> >> of decls/types to recognize
>>>>>>>>> >> the input is a declaration and call C parsing routines for parsing the
>>>>>>>>> >> whole decl)
>>>>>>>>> >
>>>>>>>>> > Yes, eventually the C frontend provides routines that can be used
>>>>>>>>> > to tentatively parse declarations / types used in the function.
>>>>>>>>> >
>>>>>>>>> >> When C front-end is invoked with -fgimple it should probably only
>>>>>>>>> >> accept functions marked as "gimple".
>>>>>>>>> >> Does this sound reasonable ?
>>>>>>>>> >
>>>>>>>>> > I think -fgimple would only enable recognizing the __GIMPLE keyword,
>>>>>>>>> > I wouldn't change all defs to GIMPLE with it.
>>>>>>>>> >
>>>>>>>>> > Richard.
>>>>>>>>> >
>>>>>>>>> >> Thanks,
>>>>>>>>> >> Prathamesh
>>>>>>>>> >>>
>>>>>>>>> >>> In private discussion we somewhat agreed (Micha - correct me ;)) that
>>>>>>>>> >>> iff the GIMPLE FE would replace the C FE function body parsing
>>>>>>>>> >>> completely (re-using name lookup infrastructure of course) and iff the
>>>>>>>>> >>> GIMPLE FE would emit GIMPLE directly (just NULL DECL_SAVED_TREE
>>>>>>>>> >>> and a GIMPLE seq in DECL_STRUCT_FUNCTION->gimple_body)
>>>>>>>>> >>> then "re-using" the C FE would be a way to greatly speed up success.
>>>>>>>>> >>>
>>>>>>>>> >>> The other half of the project would then be to change the pass manager
>>>>>>>>> >>> to do something sensible with the produced GIMPLE as well as making
>>>>>>>>> >>> our dumps parseable by the GIMPLE FE.
>>>>>>>>> >>>
>>>>>>>>> >>> Richard.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Thanks and Regards,
>>>>>>>>> Prasad Ghangal
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Thanks and Regards,
>>>>>>> Prasad Ghangal

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

[Prasad Ghangal]

Thanks everyone for suggestions,

Here is my updated proposal. I know its too late but can somebody review it?

https://drive.google.com/file/d/0B2S9OoautWxsbVBkWDY3VDNkdGc/view?usp=sharing

On 25 March 2016 at 08:46, Prathamesh Kulkarni
<prathamesh.kulkarni@linaro.org> wrote:
> On 25 March 2016 at 01:15, Prasad Ghangal <prasad.ghangal@gmail.com> wrote:
>> On 24 March 2016 at 19:01, Richard Biener <richard.guenther@gmail.com> wrote:
>>> On Thu, Mar 24, 2016 at 12:27 AM, Prasad Ghangal
>>> <prasad.ghangal@gmail.com> wrote:
>>>> Hi!
>>>>
>>>> I have attached my gsoc proposal, please review it. Let me know if I
>>>> have missed or misunderstood anything
>>>
>>> Please re-word the Abstract, it is really weird to read - I suggest to drop
>>> any notion of RTL or "back end" and somehow mention that unit testing
>>> is why "we want make changes in GIMPLE".  Also stopping compilation
>>> isn't in the scope of the project (and while maybe a nice thing to have
>>> to do less work it is not a requirement for unit testing).
>>>
>>> Thus Project Goals are only unit testing (which includes what you call
>>> start/stop compilation).
>>>
>>> During the discussion in the last comments we agreed on re-using the
>>> C frontend for decls and types only and implement a completely separate
>>> parser for the function bodies so the frontend can also emit GIMPLE directly.
>>>
>>> Thus I'd scrap 4.A)/B) and instead write about
>>>
>>>   4.
>>>     A) Define GIMPLE syntax
>>>     Provide GIMPLE dumps with enough information to parse GIMPLE and
>>>     change them according to agreed on GIMPLE syntax
>>
>> Little confused here. Don't we need to change syntax first and then
>> develop grammar to parse it?
> Well the purpose of grammar is to define the syntax.
> We would need to first define a grammar for GIMPLE and then implement
> a (predictive) parser
> that parses GIMPLE input according to our grammar and emits GIMPLE IR.
> contrived eg:
> stmt_list: stmt stmt_list_1
> stmt_list_1: stmt stmt_list_1 | epsilon
> stmt:  lvalue_operand '=' assign_stmt
>       |   'if' cond_stmt
> assign_stmt:  operand | operator operand | operand operator operand
> operand:  INT | lvalue_operand
> lvalue_operand: ID
> operator: '+'
>
> As pointed out by Richard, dumps could be modified later to adjust to
> GIMPLE syntax,
> initially you could write test-cases by hand.
>
> Thanks,
> Prathamesh
>>
>>>
>>>     B) Add __GIMPLE extension to the C FE and implement a GIMPLE parser
>>>
>>> For the suggested timeline I think that it is important for the "get
>>> basic stuff working"
>>> part to have all pieces of the project prototyped, including the pass manager
>>> support.  Otherwise there is no way to fully test part of the implementation.
>>> I'd say modifying the gimple dumps can be done last as you can always write
>>> testcases manually.
>>>
>>> I realize that the student application deadline is tomorrow.
>>>
>>> Richard.
>>>
>>>
>>>
>>>>
>>>> Thanks and Regards,
>>>> Prasad Ghangal
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 22 March 2016 at 19:23, Richard Biener <richard.guenther@gmail.com> wrote:
>>>>> On Tue, Mar 22, 2016 at 2:45 PM, Prathamesh Kulkarni
>>>>> <prathamesh.kulkarni@linaro.org> wrote:
>>>>>> On 22 March 2016 at 16:26, Richard Biener <richard.guenther@gmail.com> wrote:
>>>>>>> On Tue, Mar 22, 2016 at 12:08 AM, Prasad Ghangal
>>>>>>> <prasad.ghangal@gmail.com> wrote:
>>>>>>>> Hi!
>>>>>>>>
>>>>>>>> How exactly can we achieve start stop compilation on specific pass (ie
>>>>>>>> run single pass on input)?
>>>>>>>>
>>>>>>>> eg. $cgimple -ftree-copyrename foo.c
>>>>>>>>
>>>>>>>> should produce optimization result of -ftree-copyrename pass on foo.c input
>>>>>>>
>>>>>>> You need pass manager support and annotate each function with information
>>>>>>> on what passes should be run (in which order even?).  I think for the GSoC
>>>>>>> project specifying a starting pass for each function via the source, like
>>>>>>>
>>>>>>> __GIMPLE (tree-copyrename) void foo (void)
>>>>>>> {
>>>>>>> ...
>>>>>>> }
>>>>>>>
>>>>>>> and hacking the pass manager to honor that is enough.
>>>>>> Um would annotating each function with pass order work for ipa passes too ?
>>>>>
>>>>> There is no single point of execution for an IPA pass so no - you can
>>>>> tag it with
>>>>> one of the umbrella passes I guess.  I suppose we'd need some magic "phase"
>>>>> tags for this, like simply "IPA".  You then need to enable/disable IPA passes
>>>>> you want to run.
>>>>>
>>>>> Richard.
>>>>>
>>>>>> Thanks,
>>>>>> Prathamesh
>>>>>>>
>>>>>>> Richard.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 21 March 2016 at 09:05, Trevor Saunders <tbsaunde@tbsaunde.org> wrote:
>>>>>>>>> On Mon, Mar 21, 2016 at 04:43:35AM +0530, Prasad Ghangal wrote:
>>>>>>>>>> Hi!
>>>>>>>>>>
>>>>>>>>>> Sorry for the late reply.
>>>>>>>>>>
>>>>>>>>>> I was observing gimple dumps and my initial findings are, to parse
>>>>>>>>>> gimple, we have to add support for following components to C FE
>>>>>>>>>>
>>>>>>>>>> *basic blocks
>>>>>>>>>
>>>>>>>>> I'd think you can probably make these enough like C labels that you
>>>>>>>>> don't need to do anything special in the C fe to parse these.  Just
>>>>>>>>> removing the < and > gets you pretty close is that it?
>>>>>>>>>
>>>>>>>>>> *gimple labels and goto
>>>>>>>>>
>>>>>>>>> Similar I think.
>>>>>>>>>
>>>>>>>>>> *gimple phi functions
>>>>>>>>>>         iftmp_0_1 = PHI (ftmp_0_3, iftmp_0_4)
>>>>>>>>>
>>>>>>>>> yesI think you need to add something here.  I think you can do it as a
>>>>>>>>> builtin type function that expects its arguments to be labels or names
>>>>>>>>> of variables.
>>>>>>>>>
>>>>>>>>>> *gimple switch
>>>>>>>>>>         switch (a_1) <default: <L0>, case 1: <L1>, case 2: <L2>>
>>>>>>>>>
>>>>>>>>> I'd think we could make this more C like too.
>>>>>>>>>
>>>>>>>>>> *gimple exception handling
>>>>>>>>>
>>>>>>>>> yeah, though note exceptions are lowered pretty quickly so supporting
>>>>>>>>> them with the explicit exception syntax probably isn't particularly
>>>>>>>>> important.
>>>>>>>>>
>>>>>>>>>> *openmp functions like
>>>>>>>>>>         main._omp_fn.0 (void * .omp_data_i)
>>>>>>>>>
>>>>>>>>> I'd think you'd want to change the duping of this some to make it easier
>>>>>>>>> to tell from struct.some.member.
>>>>>>>>>
>>>>>>>>>> Please correct me if I am wrong. Also point out if I am missing anything
>>>>>>>>>
>>>>>>>>> I think you might need to do something about variable names?
>>>>>>>>>
>>>>>>>>> Trev
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 18 March 2016 at 14:53, Richard Biener <richard.guenther@gmail.com> wrote:
>>>>>>>>>> > On Fri, Mar 18, 2016 at 6:55 AM, Prathamesh Kulkarni
>>>>>>>>>> > <prathamesh.kulkarni@linaro.org> wrote:
>>>>>>>>>> >> On 15 March 2016 at 20:46, Richard Biener <richard.guenther@gmail.com> wrote:
>>>>>>>>>> >>> On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz <matz@suse.de> wrote:
>>>>>>>>>> >>>> Hi,
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> On Thu, 10 Mar 2016, Richard Biener wrote:
>>>>>>>>>> >>>>
>>>>>>>>>> >>>>> 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).
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> I think it's wrong to try to shoehorn the gimple FE into the C FE.  C is
>>>>>>>>>> >>>> fundamentally different from gimple and you'd have to sprinkle
>>>>>>>>>> >>>> gimple_dialect_p() all over the place, and maintaining that while
>>>>>>>>>> >>>> developing future C improvements will turn out to be much work.  Some
>>>>>>>>>> >>>> differences of C and gimple:
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> * C has recursive expressions, gimple is n-op stmts, no expressions at all
>>>>>>>>>> >>>> * C has type promotions, gimple is explicit
>>>>>>>>>> >>>> * C has all other kinds of automatic conversion (e.g. pointer decay)
>>>>>>>>>> >>>> * C has scopes, gimple doesn't (well, global and local only), i.e. symbol
>>>>>>>>>> >>>>   lookup is much more complicated
>>>>>>>>>> >>>> * C doesn't have exceptions
>>>>>>>>>> >>>> * C doesn't have class types, gimple has
>>>>>>>>>> >>>> * C doesn't have SSA (yes, I'm aware of your suggestions for that)
>>>>>>>>>> >>>> * C doesn't have self-referential types
>>>>>>>>>> >>>> * C FE generates GENERIC, not GIMPLE (so you'd need to go through the
>>>>>>>>>> >>>>   gimplifier and again would feed gimple directly into the passes)
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> I really don't think changing the C FE to accept gimple is a useful way
>>>>>>>>>> >>>> forward.
>>>>>>>>>> >>>
>>>>>>>>>> >>> So I am most worried about replicating all the complexity of types and decl
>>>>>>>>>> >>> parsing for the presumably nice and small function body parser.
>>>>>>>>>> >> Um would it be a good idea if we separate "gimple" functions from
>>>>>>>>>> >> regular C functions,
>>>>>>>>>> >> say by annotating the function definition with "gimple" attribute ?
>>>>>>>>>> >
>>>>>>>>>> > Yes, that was my idea.
>>>>>>>>>> >
>>>>>>>>>> >> A "gimple" function should contain only gimple stmts and not C.
>>>>>>>>>> >> eg:
>>>>>>>>>> >> __attribute__((gimple))
>>>>>>>>>> >> void foo(void)
>>>>>>>>>> >> {
>>>>>>>>>> >>   // local decls/initializers in C
>>>>>>>>>> >>   // GIMPLE body
>>>>>>>>>> >> }
>>>>>>>>>> >> Or perhaps we could add a new keyword "gimple" telling C FE that this
>>>>>>>>>> >> is a GIMPLE function.
>>>>>>>>>> >
>>>>>>>>>> > Though instead of an attribute I would indeed use a new keyword (as you
>>>>>>>>>> > can't really ignore the attribute and it should be an error with compilers
>>>>>>>>>> > not knowing it).  Thus sth like
>>>>>>>>>> >
>>>>>>>>>> > void foo (void)
>>>>>>>>>> > __GIMPLE {
>>>>>>>>>> > }
>>>>>>>>>> >
>>>>>>>>>> > as it's also kind-of a "definition" specifier rather than a
>>>>>>>>>> > declaration specifier.
>>>>>>>>>> >
>>>>>>>>>> >>
>>>>>>>>>> >> My intention is that we could reuse C FE for parsing types and decls
>>>>>>>>>> >> (which I suppose is the primary
>>>>>>>>>> >> motivation behind reusing C FE) and avoid mixing C statements with
>>>>>>>>>> >> GIMPLE by having a separate
>>>>>>>>>> >> GIMPLE parser for parsing GIMPLE functions.
>>>>>>>>>> >> (I suppose the GIMPLE function parser would need to do minimal parsing
>>>>>>>>>> >> of decls/types to recognize
>>>>>>>>>> >> the input is a declaration and call C parsing routines for parsing the
>>>>>>>>>> >> whole decl)
>>>>>>>>>> >
>>>>>>>>>> > Yes, eventually the C frontend provides routines that can be used
>>>>>>>>>> > to tentatively parse declarations / types used in the function.
>>>>>>>>>> >
>>>>>>>>>> >> When C front-end is invoked with -fgimple it should probably only
>>>>>>>>>> >> accept functions marked as "gimple".
>>>>>>>>>> >> Does this sound reasonable ?
>>>>>>>>>> >
>>>>>>>>>> > I think -fgimple would only enable recognizing the __GIMPLE keyword,
>>>>>>>>>> > I wouldn't change all defs to GIMPLE with it.
>>>>>>>>>> >
>>>>>>>>>> > Richard.
>>>>>>>>>> >
>>>>>>>>>> >> Thanks,
>>>>>>>>>> >> Prathamesh
>>>>>>>>>> >>>
>>>>>>>>>> >>> In private discussion we somewhat agreed (Micha - correct me ;)) that
>>>>>>>>>> >>> iff the GIMPLE FE would replace the C FE function body parsing
>>>>>>>>>> >>> completely (re-using name lookup infrastructure of course) and iff the
>>>>>>>>>> >>> GIMPLE FE would emit GIMPLE directly (just NULL DECL_SAVED_TREE
>>>>>>>>>> >>> and a GIMPLE seq in DECL_STRUCT_FUNCTION->gimple_body)
>>>>>>>>>> >>> then "re-using" the C FE would be a way to greatly speed up success.
>>>>>>>>>> >>>
>>>>>>>>>> >>> The other half of the project would then be to change the pass manager
>>>>>>>>>> >>> to do something sensible with the produced GIMPLE as well as making
>>>>>>>>>> >>> our dumps parseable by the GIMPLE FE.
>>>>>>>>>> >>>
>>>>>>>>>> >>> Richard.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Thanks and Regards,
>>>>>>>>>> Prasad Ghangal
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Thanks and Regards,
>>>>>>>> Prasad Ghangal