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" <
> lopeziba...@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.
>
>
