Re: Integration of ISL code generator into Graphite

[Mircea Namolaru <mircea dot namolaru at inria dot fr>]

Hi,

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 
attributes). 
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)

Mircea


----- Original Message -----
> From: "Tobias Grosser" <tobias@grosser.es>
> To: "Mircea Namolaru" <mircea.namolaru@inria.fr>, "Roman Gareev" <gareevroman@gmail.com>
> Cc: gcc@gcc.gnu.org, "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?
> 
> Tobias
> 
>