This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]