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?
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
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.
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.
Cheers,
Manuel.
