Re: Simplifying Gimple Generation

[Andrew MacLeod <amacleod@redhat.com>]

On 11/14/2012 08:13 PM, Lawrence Crowl wrote:
> Diego and I seek your comments on the following (loose) proposal.
>
>
>
> We propose a simplified form using new build helper classes ssa_seq
> and ssa_stmt that would allow the above code to be written as
> follows.
>
> ssa_seq q;
> ssa_stmt t = q.stmt (NE_EXPR, shadow, 0);
> ssa_stmt a = q.stmt (BIT_AND_EXPR, base_addr, 7);
> ssa_stmt b = q.stmt (shadow_type, a);
> ssa_stmt c = q.stmt (PLUS_EXPR, b, offset);
> ssa_stmt d = q.stmt (GE_EXPR, c, shadow);
> ssa_stmt e = q.stmt (BIT_AND_EXPR, t, d);
> q.set_location (location);
> r = e.lhs ();
<...>
>
> There will be another class of builders for generating GIMPLE
> in normal form (gimple_stmt).  We expect that this will mostly
> affect all transformations that need to generate new expressions
> and statements, like instrumentation passes.
I certainly like the general idea.

Have you actually sat down and worked out the interface?  Do we really 
need a set of SSA *and* a set of gimple routines? I fooled around with a 
few variations and it doesn't seem like we should.

It seems to me that SSA is just a specialization of gimple, so I would 
think maybe a very small set of SSA specializations could be applied to 
the gimple interface.   All the statement linking, manipulation and 
accessing is identical, so maybe something as simple as making the 
stmt() method have 2 variations on whether you want SSA results or not 
in the gimple expression.

GimpleSeq q;
GimpleStmt t = q.ssa_stmt (NE_EXPR, shadow, 0);
GimpleStmt a = q.ssa_stmt (BIT_AND_EXPR, base_addr, 7);
GimpleStmt b = q.ssa_stmt (shadow_type, a);

Any accesses to 'a' when you are generating code is going to pick up the LHS of the expression, whether its SSA or not. So if you want gimple generated instead of SSA, you do something like
GimpleStmt b = q.gimple_stmt (shadow_type, a);  // result is just a gimple temp insterad of ssa temp

And would the GimpleStmt class give you access to ALL the gimple_YYY access routines?  ie,  b.has_ops() instead of gimple_has_ops (b)

This would certainly help pave the way for replacing the gimple data structure with a proper object eventually.

The GinmpleSeq object which affects everything in the sequence... I presume there is just a subset of the methods which would be available.. ie set_use_ops() would clearly not make sense. Have you enumerated which routines that would be, or just leave that until its actually implemented?

We may find there are other interesting uses of the GimpelSeq object along the way as well.


>
> We also expect to reduce calls to tree expression builders by
> allowing the use of numeric and string constants to be converted
> to the appropriate tree _CST node.  This will only work when the
> type of the constant can be deduced from the other argument in some
> expressions, of course.
>
<...>

I think this would be great.. I find I'm constantly having to look up 
the right thing to do and it annoys me to no end that I cant just say 0 
when I mean 0. or "a string". I have to look up the correct way to get 
everything back as well...
>
> Proposal
>
> Create a set of IL builder classes that provide a simplified IL
> building interface.  Essentially, these builder classes will abstract
> most of the bookkeeping code required by the current interfaces.
>
> These classes will not replace the existing interfaces.  We do not
> expect that all the IL generation done in current transformations
> will be able to use the simplified interfaces.  The goal is to
> simplify most of them, however.
The long term goal *would* be a complete replacement, so as long as that 
is kept in mind and these changes help move in that direction, then I 
think the effort is worthwhile.

Andrew