This is the mail archive of the
mailing list for the GCC project.
Re: [gimplefe] [gsoc16] Gimple Front End Project
- From: David Malcolm <dmalcolm at redhat dot com>
- To: Manuel López-Ibáñez <lopezibanez at gmail dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, Trevor Saunders <tbsaunde at tbsaunde dot org>, Prasad Ghangal <prasad dot ghangal at gmail dot com>, Diego Novillo <dnovillo at google dot com>, gcc Mailing List <gcc at gcc dot gnu dot org>, sandeep at gcc dot gnu dot org
- Date: Tue, 08 Mar 2016 16:59:47 -0500
- Subject: Re: [gimplefe] [gsoc16] Gimple Front End Project
- Authentication-results: sourceware.org; auth=none
- References: <CAE+uiWabe9W088+CaKh+8VgSdadk+pyt2C6QEbxgj=bQs=Nkdg at mail dot gmail dot com> <CAE+uiWajGum8ccJer8E9w56KVm_VcM8jXB2atXSwpWeuYenFpg at mail dot gmail dot com> <CAD_=9DSJBCdKtY+K2FDt5FS85hAue7MznyUX2Z4RUffOmuoDFA at mail dot gmail dot com> <FA69E188-E41B-4A3C-AC4A-2D21F0ADA713 at gmail dot com> <CAE+uiWbJ7+mY_2xYNQBTT1emXf5J+E79nK+c2cE2u1Deh8Zf=w at mail dot gmail dot com> <CAFiYyc2_93J4K7vNDZngW=5wMxUK1s+JxQo2k7TByUkDT_cz7w at mail dot gmail dot com> <1457368435 dot 9813 dot 68 dot camel at redhat dot com> <20160308002418 dot GA13433 at ball> <56DEF2F1 dot 1080900 at gmail dot com> <A7AF86B3-A2D2-429B-99B0-BDA1F345251A at gmail dot com> <1457455668 dot 9813 dot 106 dot camel at redhat dot com> <CAESRpQA-TKoQ85X9jbE7VKnCpR4oiAnH4Dsnnxmxa03oZsUjLg at mail dot gmail dot com>
On Tue, 2016-03-08 at 21:00 +0000, Manuel LÃpez-IbÃÃez wrote:
> On 8 March 2016 at 16:47, David Malcolm <firstname.lastname@example.org> wrote:
> > > > 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.
> -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
> > > > 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)
> 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
> > 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?
> > (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)
> > (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.
AIUI, Richard would also like:
(F) the form to be parsable as C
(presumably some subset)
LLVM IR is likely similar to GIMPLE IR, but AFAIK, LLVM IR requires
SSA, which would seem to preclude using it (goals (D) and (E) above).
Also, there may be other things we'd want to express in GIMPLE that
might not be directly expressible in LLVM IR (Richard alluded to this
earlier in this thread: the on-the-side data: range info, points-to
info, etc). Though I suspect converters may be feasible for some
common subset of SSA IR.
Regarding goal (F) above, AFAIK, LLVM IR has a texual assembly form and
a bitcode form; does LLVM IR have a subset-of-C form?