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

[David Malcolm <dmalcolm at redhat dot com>]

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