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 03/08/2016 02:59 PM, David Malcolm wrote:
On Tue, 2016-03-08 at 21:00 +0000, Manuel LÃpez-IbÃÃez wrote:
On 8 March 2016 at 16:47, David Malcolm <> 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,
based on
dependencies and re-configurable like I wonder how far
away is
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
stuff needed.

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
the advantages/disadvantages.

My goal for unit-testing passes is to be able to dump/reload the GIMPLE
IR in a form that's:
   (A) readable by both humans and programs, and
   (B) editable by humans
   (C) roundtrippable for some subset of the IR
   (D) can support the input for every gimple pass (pre-CFG, CFG-before
-SSA, CFG-with-SSA, with/without lowered switches etc)
   (E) can support the output of every gimple pass, apart from the final
expansion to RTL.
I'll come back to my assertion that this really should be reading/writing a textual LTO.

By definition, everything we need is currently streamed in/out by the LTO bits. What's needed is (in essence) is to virtualize that interface to have textual forms.


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