This is the mail archive of the
mailing list for the GCC project.
Re: [gimplefe] [gsoc16] Gimple Front End Project
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Diego Novillo <dnovillo at google dot com>
- Cc: Andrew MacLeod <amacleod at redhat dot com>, David Malcolm <dmalcolm at redhat dot com>, Prasad Ghangal <prasad dot ghangal at gmail dot com>, gcc Mailing List <gcc at gcc dot gnu dot org>, sandeep at gcc dot gnu dot org
- Date: Wed, 9 Mar 2016 17:35:57 +0100
- 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> <56E032E1 dot 3020909 at redhat dot com> <CAFiYyc3x-VHZvKWeR9bfs8WvvP9GzP7sxaaF+pC+vbjfZHo_2w at mail dot gmail dot com> <CAD_=9DRdJTF_4DRw+PGGNzyuGEiGEfAefc4C5AKZf5bZT5LupQ at mail dot gmail dot com>
On Wed, Mar 9, 2016 at 5:07 PM, Diego Novillo <email@example.com> wrote:
> On Wed, Mar 9, 2016 at 10:47 AM, Richard Biener
> <firstname.lastname@example.org> wrote:
>> About using the LLVM IR - similar issue I think, plus it is probably
>> too far away
>> from GCC so that what we'll end up will only look like LLVM IR but not actually
>> be LLVM IR.
> I don't think this is feasible at all, actually. As I said in my
> message, LLVM IR and GIMPLE are fairly different in terms of
> The main goal is providing a text-based representation for GIMPLE that
> can be used as input into any arbitrary stage of the optimizer. This
> also implies other modularization efforts that allow this.
> Whether or not GIMPLE looks like C, or this is done piggybacking the C
> FE, is a different issue. I think the first issue to solve is
> defining GIMPLE as a full, compilable language with well formed
> execution and data semantics.
I don't think that's necessary. GIMPLE is an implementation detail and it
should remain that. For unit testing it's only required to be able to input
sth resembling GIMPLE close enough. All is necessary is to define
execution and data semantics of the C extensions we need to get "close enough".
After all GIMPLEs execution and data semantics are basically Cs (with some
extras not covered by C).