On 8 March 2016 at 16:47, David Malcolm <email@example.com> wrote:
Isn't this what -fopt-info does?
One difference is that in this proposal, the output is emitted as a
diagnostic, rather than to a file.
-fopt-info prints to stderr by default. I haven't used the current
version. The original version of -fopt-info was very similar to what
you described above.
FWIW, I find those existing options to be very fiddly to use (and
they're categorized as "GCC Developer Options").
Not sure what you mean exactly by fiddly. I think they are
as "GCC Developer Options" because the main users are developers
working on GCC optimizations, and there has been little interest in
making the output consistent and user-friendly. I seem to remember
that the original proposal by Google devs was to make -fopt-info a
for users to understand how their code was or not optimized. That
would not match your description either, because you want to use it
for unit-testing, thus it will still be a "developer" option.
Of course, ideally, the pass manager would be all modular,
dependencies and re-configurable like
http://llvm.org/docs/CommandGuide/opt.html I wonder how far
middle-end from being able to do that.
For any kind of unit testing you need to develop some pass
Which seems orthogonal to having a gimple-fe. That is, a gcc version
of the llvm opt tool would be useful even if it needed to go through
the existing FEs. It would be very useful to unit-testing specific
passes or sequences of passes. It would also be pretty
uncontroversial. And not something that a GSoC student could even
attempt, given the need to spent significant time/effort in coming up
with an overall design for the pass manager.
This is possibly a silly question, but why would a custom C-like FE
a language that isn't quite C rule out torturing unit tests? Can't
inject the gimple at the stage it was generated, and then supply
various -O options to run various combinations of passes?
(Though hacking up the C frontend might be a suitable way to
a dedicated gimple frontend; runs into issues of having them
I don't know how much we'd want in common vs how much has to be
(potentially we could define a subset of e.g. C99 that would be
acceptable as gimple. I don't know if that's helpful)
A first step would be to dump something that is parseable as a subset
of C. I don't think we are nowhere near that. And that would still
be enough, since I don't think we dump all details of gimple. The C
also would need to be able to parse as gimple things like look like C
but are significantly different (like Fortran explicit parentheses).
Adding stuff to the C FE might seem the fast path forward, but we
end up with a gimple-fe as complex as the whole C FE plus the extra
bits for parsing all the non-C stuff. That seems very undesirable in
the long run. To be clear, what I would propose if a C-like
representation is desired is "cp -a c cgimple", and start deleting
the things that are not needed by cgimple and adding all the extra
Since the goal seems to be to be able to dump/reload some kind of IR
rather than a textual representation of GIMPLE tuples, why not
dump/load LLVM IR? The GIMPLE=>LLVM is already implemented as a GPL
plugin in dragonegg.
It is not a suggestion, but I would like to know what you think about