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