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

[David Malcolm <dmalcolm at redhat dot com>]

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