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
patch
Description: Binary data