This is the mail archive of the 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 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

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?

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]

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?

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 I wonder how far away is GCC's middle-end from being able to do that.

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

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.



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