This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]