[gimplefe] [gsoc16] Gimple Front End Project

[Trevor Saunders]

On Tue, Mar 08, 2016 at 05:12:56PM -0500, Diego Novillo wrote:
> On Tue, Mar 8, 2016 at 4:59 PM, David Malcolm <dmalcolm@redhat.com> wrote:
> 
> > 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).
> 
> LLVM IR is an SSA IR, yes.  It also has two different representations,
> a text-based one parseable with its front end, and a binary one
> (bitcode) which is more efficient for purposes of LTO and such
> (similar to the GIMPLE bytecode lto front end).
> 
> LLVM IR is actually lower in the IR abstraction spectrum.  It's closer
> to RTL than it is to GIMPLE.  For instance, its type system is very
> similar to RTL: words, pointers and offsets.  A few machine features
> creep in, but not many.  Things like function calls look very much
> like a C function call.
> 
> 
> >  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?
> 
> Well, in the sense that it kinda looks like a very low level version
> of C.  For instance,
> 
> int sum(int y, int x) { return x + y; }
> 
> becomes:
> 
> define i32 @sum(i32 %y, i32 %x) #0 {
> entry:
>   %y.addr = alloca i32, align 4
>   %x.addr = alloca i32, align 4
>   store i32 %y, i32* %y.addr, align 4
>   store i32 %x, i32* %x.addr, align 4
>   %0 = load i32, i32* %x.addr, align 4
>   %1 = load i32, i32* %y.addr, align 4
>   %add = add nsw i32 %0, %1
>   ret i32 %add
> }
> 
> Notice all the word operations and the SSA nature of the IL itself.
> 
> 
> I'm hardly in a position to offer guidance here, but I'm not sure that
> overloading the gimple FE on the c-family FE is desirable long term.

I'm kind of on the fence there.

> The two parsers are going to invariably differ in what they want to
> accept, error messages, etc.  For modularity purposes, having a

I'm not sure they really will so far as types are concerned.  As far as
expressions and statements go they probably should be different.

> separate module dealing with GIMPLE itself might be better than
> piggybacking functionality on the C FE.

My concern is that writing a separate gimple parser will require
basically a copy of all the code to parse decls and types, but maybe
that isn't that much?

> This way, implementing a library that supports dealing with GIMPLE
> becomes much simpler.  This provides a nice foundation for all kinds
> of gimple-oriented tooling in the future.

Well, one nice thing about choosing a subset of C as your textual
representation of gimple is that all the tools that deal with C already
can deal with it, and so you won't really need separate tools for gimple
(that would be my theory anyway).

Trev

> 
> 
> 
> Diego.