Hi Tobias,

> Allright. It seems you understood the tree traversel. For the actual
> patch that we want to commit, let's leave it out for now.  Instead,
> let's try to get a minimal patch that only adds the flag and the new
> file for the isl_ast stuff. In case the isl is choosen as code
> generation option, the cloog pass is disabled (they would otherwise get
> into their way later) and we dump the ast. We also need a simple test case
> that checks that the dump is generated.

What do you mean by simple test case that checks that the dump is
generated? Is it checking of the dump_flags?

> Instead of adding this functionality to gloog() I would create a
> semilar function that provides the functionality gloog has for the isl
> codegen counterpart. -fgraphite-code-generator switches then between
> these two functions. To start with the isl counterpart is almost empty.
> It just contains the parts of this patch needed for printing. When we
> add more functionality and we encounter reuse opportunities, we can move
> parts of graphite-clast-to-gimple.c into a generic codegen file.
>
> What do you think?

I think that it's good. It would help to begin removing of CLooG
dependency and make the file with generation of ISL AST easier to
maintain. I implemented it in the patch, which can be found below. You
can also find my post about my second task of the proposal at the
following link http://romangareev.blogspot.com/2014/05/gsoc-report-ii.html

--
                                   Cheers, Roman Gareev

Attachment: patch
Description: Binary data

Reply via email to