Re: Integration of ISL code generator into Graphite

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

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. The computation of 
these attributes may requires several traversals of the AST tree, depending
on the complexity of attribute that you need to compute. After you
computed the required attributes, an additional traversal is used to
generate the code. You may see CLOOG as using a single traversal of 
CLOOG AST where computation of attributes is interleaved with code generation.

2. The underlying design for polyhedral code generation in Graphite

Polyhedral representation -> AST -> tree SSA.

remains the same, but the CLOOG AST is replaced by the ISL AST. 
Semantically these two AST are rather similar both encoding the structure 
of the tree SSA code to be generated - take advantage of this and reuse as 
much as possible existent code. Due to time constraints reuse of existing code 
is a key point for this project.

3. A possible road map:
- Identify the attributes used by CLOOG AST code generation and how they are used to 
generate tree-SSA code.
- Compute the attributes found for the ISL AST (part of them may be already there
under a different name). 
- Modify the current AST CLOOG generation part to be attribute driven - this will
made possible its use by ISL AST (which as this stage has the required attributes).

For the implementation you may start with a subset of attributes, perform these
three steps for them - and then incrementally add new attributes.

Hope that this attribute based approach is helpful for you. 

Regards,
Mircea  


----- Original Message -----
> From: "Tobias Grosser" <tobias@grosser.es>
> To: "Roman Gareev" <gareevroman@gmail.com>
> Cc: gcc@gcc.gnu.org, "Albert Cohen" <Albert.Cohen@inria.fr>, "Mircea Namolaru" <mircea.namolaru@inria.fr>
> Sent: Friday, March 21, 2014 12:51:26 PM
> Subject: Re: Integration of ISL code generator into Graphite
> 
> On 03/21/2014 12:04 PM, Roman Gareev wrote:
> > Hi Tobias,
> >
> > thank you for all your comments! I've tried to consider them in the
> > improved version of my proposal, which can be found at the following
> > link
> > https://drive.google.com/file/d/0B2Wloo-931AoeUlYOHhETVBvY3M/edit?usp=sharing
> > .
> >
> >> - In unreleased isl 0.13.0, support for compute out feature
> >
> > I haven't found information about this feature and isl 0.13.0. Could
> > you please give me a link to be referred to in the proposal?
> 
> Section 1.4.1 of the isl manual documents the following functions:
> 
> void isl_ctx_set_max_operations(isl_ctx *ctx,
> unsigned long max_operations);
> unsigned long isl_ctx_get_max_operations(isl_ctx *ctx);
> void isl_ctx_reset_operations(isl_ctx *ctx);
> 
> >> - Improved code generation quality
> >
> > I also haven't found code quality comparison between CLooG and ISL
> > code generator. Do you mean, that ISL code generator can improve code
> > quality with unrolling, full/partial tile separation, fine-grained
> > code size adjustments?
> 
> We have an unpublished paper on this. We should probably make this a
> tech report at some point.
> 
> >> - "New internal representaion will be generated by ISL. Its structure is
> >> planned to be similar to the CLAST tree, but can be changed ..."
> >>
> >> What does this  mean? The isl_ast representation is already defined. Are
> >> you
> >> saying that isl may generate an ast that is different in structure to the
> >> clast tree currently generated? Or are you saying we
> >> still need to define the isl_ast and its nodes itself?
> >
> > I wanted to say that ISL will generate ISL AST from the polyhedral
> > representation. This ISL AST (with pointers to original basic blocks
> > instead of statments) will be internal representation for Graphite,
> > that should be traversed and transformed into the GIMPLE CFG. I
> > eliminated the mention of this internal representation in the improved
> > version of the proposal.
> 
> Good.
> 
> I think this proposal is already very nice. I have some last comments in
> case you want to really polish it:
> 
> o 26-31 May: Get familiar with CLooG generation?
> 
> Why is this necessary?
> 
> 
> Also, for the remaining time-line, I think you could start working on
> making this more detailed.
> 
> Instead of having separate testing and fixing bug weeks, I think it
> would be optimal to have for each weak one topic that you plan to finish
> (including testing and fixing), as well as a brief idea how to do it.
> You already have a good idea of what is needed, but you could detail
> this further by looking through the exiting source code (or by looking
> into Polly's IslCodeGeneration.cpp) to see what is needed.
> 
> In which week are you e.g. planning to write the code to generate
> isl_ast_expr?
> 
> Which pieces of the code are you planning to reuse?
> 
> Are you planning to split of pieces of the code that can be shared by
> CLooG and isl, before fully removing CLooG?
> 
> Cheers,
> Tobias
> 
> 
> 
> 
>