This is the mail archive of the
mailing list for the GCC project.
Re: FW: Question about Gimple FE
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Sebastian Pop <sebpop at gmail dot com>
- Cc: Jeff Law <law at redhat dot com>, Diego Novillo <dnovillo at google dot com>, xue yinsong <xyshh94225 at hotmail dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Tue, 7 Apr 2015 10:33:13 +0200
- Subject: Re: FW: 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> <6B559995-4BD4-4EC3-B8B0-6261767B8740 at hotmail dot com> <BLU436-SMTP6095BDF79AC949FCD664E485F10 at phx dot gbl> <CAD_=9DR9pZ6TSA-73kzeEPo+=3-PsCUQhEynn=-vF=gOoQ0J8A at mail dot gmail dot com> <551EB355 dot 8010607 at redhat dot com> <CAD_=9DSp5bniJ+uPTyLqS+GP-ERPudzgcLSDuZ2BR7Q64V3g4w at mail dot gmail dot com> <551ED79D dot 60703 at redhat dot com> <CAFk3UF9Q0WuODC5p61WkHT2_2s+jMv3jMfDX6BPWnENUG36F7Q at mail dot gmail dot com>
On Mon, Apr 6, 2015 at 11:20 PM, Sebastian Pop <firstname.lastname@example.org> wrote:
> On Fri, Apr 3, 2015 at 1:10 PM, Jeff Law <email@example.com> wrote:
>> On 04/03/2015 09:41 AM, Diego Novillo wrote:
>>> On Fri, Apr 3, 2015 at 11:35 AM, Jeff Law <firstname.lastname@example.org> wrote:
>>> I was hesitant to offer this option, but it's certainly a good
>>> starting point. The representation encodes CFG, SSA, attributes,
>>> declarations and annotations. It has a relatively fixed syntax, which
>>> makes it easy to parse.
>> Certainly using LLVM's textual format opens up a significant cans of worms,
>> but there's some obvious (and some less than obvious) benefits.
> I also want to mention that LLVM's IR is not an equivalent of GCC's IR:
> for instance, in GCC we have multi dimensional array types that are
> missing in LLVM.
> Having an IR that is more readable than LLVM's would be nice.
I still like the idea of using C + extensions most. As well as making the
-fdump-tree-XXX dumps (more) valid C (+ extensions). Cut & pasting
from dump files to generate testcases is currently somewhat awkward,
mainly due to the issue how we dump labels + goto destinations.