Integration of ISL code generator into Graphite

[Tobias Grosser]

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