This is the mail archive of the
mailing list for the GCC project.
Re: Question about Gimple FE
- From: Jeff Law <law at redhat dot com>
- To: Diego Novillo <dnovillo at google dot com>, xue yinsong <xyshh94225 at hotmail dot com>, Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Fri, 03 Apr 2015 09:25:57 -0600
- Subject: Re: Question about Gimple FE
- Authentication-results: sourceware.org; auth=none
- References: <BLU436-SMTP393D735E667D7744698A4D85080 at phx dot gbl> <CAFiYyc0ukmm0w+YPQ1QOV2Vw3euPmVZR2MLHsjc25XB9T0ds8w at mail dot gmail dot com> <BLU436-SMTP23617265C8657F936DF78CF85090 at phx dot gbl> <CAFiYyc3Ryj6mj9o-JeJwfBHfHavQDD-iA_8gW9taoUEehKLWdw at mail dot gmail dot com> <CAFiYyc2eje=Fx5DRRDOktqvv0=MDp8vK54AKvKuwWRbM4u5-DQ at mail dot gmail dot com> <BLU437-SMTP126C99D3E9C8BD08E2658385F10 at phx dot gbl> <551E9992 dot 7020608 at google dot com>
On 04/03/2015 07:45 AM, Diego Novillo wrote:
On 04/02/15 11:59, xue yinsong wrote:
I suppose our goal is to translate the dumped program back to
the C source code (otherwise we can simply retain the gotos and
labels since they are already `validâ in C). In this case we have to
convert the gotos back to if-elses and whiles. As long as
CFG informations are given, itâs possible to get rid of these gotos.
Not quite. The output of the debug dumpers is not really meant to be fed
back to the compiler. They are debug dumps only. They do not contain
enough information for code generation or analysis.
But that's something that could be fixed.
I think the fundamental question is whether or not to start with the
debug dumps or from scratch with a new format. Either way we want a
format that is easily readable back into the compiler, but also easily
modifable by a human or a preprocessor for test generation.
What's also interesting here is David's work which is a step towards
allowing a program to generate gimple and inject it into the compiler at
interesting points. So we could have a generator program which
generates gimple, feeds it into a pass, then verifies the result. What
I'm struggling with here is balancing the human cost of building a test
in David's kind of framework vs doing something easier in a gimple-FE
like framework vs what we do now where it's bloody hard to arrange for
bits to get to a specific pass in a specific state.