This is the mail archive of the gcc@gcc.gnu.org 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 Wed, Mar 9, 2016 at 5:07 PM, Diego Novillo <dnovillo@google.com> wrote:
> On Wed, Mar 9, 2016 at 10:47 AM, Richard Biener
> <richard.guenther@gmail.com> 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
> abstraction.
>
> 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).

Richard.

>
> Diego.


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