On 16/05/2014 21:49, Roman Gareev wrote:
Hi Tobias,
what is the difference you see between ISL AST generation and code
generation?
By “ISL AST generation”, I mean ISL AST generation without generation
of GIMPLE code.
Alright.
What are your plans to separate the ISL AST generation? Do you foresee any
difficulties/problems?
According to the plan mentioned in my proposal, I wanted to get more
familiar with ISL AST generation by generation of ISL AST in a file,
which is separate from the GCC sources. This could help to avoid
problems with interpretation and verification of results, because I
worked with my own input to ISL AST generator instead of the input
built by Graphite from GIMPLE code. This could also help to avoid
rebuilding of GCC in the process of debugging. However, I've come to
the conclusion that the way you advised me is better, because it helps
to save the time of integration of ISL AST generation in GCC.
I've set up a second code generation in parallel that generates ISL
AST and can be enabled by a command line flag. Could you please advise
me how to verify the results of this generation?
Below is the code of this generation.
This looks in general good. A couple of comments:
1. Could you send the file as patch to the gcc repository
(e.g. created by git)
2. You seem to miss the build system integration
3. Several lines cross 80 columns
4. We also need a place to dump the isl output.
To output the isl_ast you can use the following pattern:
if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file,
"Loops at depths %d and %d will be interchanged.\n",
depth1, depth2);
It will then show up in the graphite tree dump file (enabled by
-fdump-tree-graphite-all ). You can then hopefully match the output in
the dejagnu tests, but I am unsure how exactly multi-line matching
works. If you don't find a solution easily it may be worth asking on the
gcc mailing list for this feature.
Cheers,
Tobias
