This is the mail archive of the
mailing list for the GCC project.
Re: Integration of ISL code generator into Graphite
- From: Mircea Namolaru <mircea dot namolaru at inria dot fr>
- To: Tobias Grosser <tobias at grosser dot es>
- Cc: Roman Gareev <gareevroman at gmail dot com>, gcc at gcc dot gnu dot org, Albert Cohen <Albert dot Cohen at inria dot fr>
- Date: Thu, 27 Mar 2014 14:17:52 +0100 (CET)
- Subject: Re: Integration of ISL code generator into Graphite
- Authentication-results: sourceware.org; auth=none
- References: <CABGF_geM-zis3uxcUvzm-jgQ-=ehHB2P1kRFrAyv9=JOeB8J+w at mail dot gmail dot com> <532A0625 dot 8060208 at grosser dot es> <CABGF_gepvy1jxyF87WhqYC3NX08orbuXRoaL154DaJMEwjX2ZQ at mail dot gmail dot com> <532C27BE dot 8020008 at grosser dot es> <945345893 dot 118503 dot 1395666528384 dot JavaMail dot zimbra at inria dot fr> <53302F15 dot 6080408 at grosser dot es>
Look at the attributes as defining the interface provided by AST to the code generator.
The code generator will work with any AST providing this interface. As you want to reuse the
existing code, its structure affects the way in which you define this interface (i.e. the
The most important attribute is the AST node type as currently TREE SSA code generation
is driven by the type of the node. Other fields from clast struct are also good
candidates for being considered attribute. But to copy all the fields from CLOOG AST
into ISL AST (this will allow to preserve the current code) may not be a good solution.
Instead a more flexible approach may be preferable where parts of the code are preserved,
while other parts are restructured or completely rewritten. Determining this partition of
the code is related with attributes definition.
The types used in functions from graphite_clast_to_gimple.c provides a good
criteria for performing this partition. Functions that use types related to tree
SSA representation (CFG, induction variable etc), SCOP etc. are good candidates to be
preserved or restructured. It depends of how you want to continue to access the information from
CLAST CLOOG information in these functions - 1) continue to use the same fields from CLAST (but as
fields of ISL AST). etc, then each field define an attribute, or 2) collapse multiple CLAST etc fields
in a single attribute. In the later case the code computing this attribute need to be enclosed in a
function/macro returning it. The attributes found may be already in the AST ISL but under a different
name, or they need to be computed. Once the ISL AST tree is able to provide these
attributes the functions accessing them could be preserved - the access to these attributes should be
done via macro/functions/types to hide their implementation. Functions accessing only CLAST,CLOOG types
are good candidates to be restructured or rewritten.
This would be the underlying idea. Of course in practice a lot depends on the structure of the current
code. Maybe start by analysing what types are used in the functions used by tree-SSA code generation.
This will show you in what measure the code that you will want to keep (code using tree-SSA related
types etc) is interleaved with code that you need to adopt or rewrite (code using CLAT, CLOOG data types).
Depending on this, you may decide the relation between the ISL AST based code generation and CLOOG AST code
generation in terms of preserve/restructure/rewrite. Another factor that needs to be taken into account is
the time needed to stabilize the code (new written parts may take much longer time)
----- Original Message -----
> From: "Tobias Grosser" <firstname.lastname@example.org>
> To: "Mircea Namolaru" <email@example.com>, "Roman Gareev" <firstname.lastname@example.org>
> Cc: email@example.com, "Albert Cohen" <Albert.Cohen@inria.fr>
> Sent: Monday, March 24, 2014 2:11:49 PM
> Subject: Re: Integration of ISL code generator into Graphite
> On 03/24/2014 02:08 PM, Mircea Namolaru wrote:
> > Hi,
> > 1. Maybe there is also an opportunity to improve the design of Graphite
> > code generation, this will give you another benefit - code more robust,
> > easier
> > to maintain and extend.
> > I suggest a design where the code generation from ISL AST is based
> > on attributes (properties) of the ISL AST nodes.
> Hi Mircea,
> could you give examples of the 'attributes' you are thinking of?