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" <tob...@grosser.es> > To: "Mircea Namolaru" <mircea.namol...@inria.fr>, "Roman Gareev" > <gareevro...@gmail.com> > Cc: gcc@gcc.gnu.org, "Albert Cohen" <albert.co...@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 > >
