This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Simplifying Gimple Generation
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