Details about the project
After scop formation in “build_poly_scop()”, scops are optimized through “scop_do_block()”, “scop_do_strip_mine()” and “scop_do_interchange()”. After these optimizations, we export the scop (dump it) to a text file in special standard format (scop format) readable by other standard polyhedral tools (and human readable also). After scop dumping, the tool reads the scop file, applies appropriate polyhedral transformations that are not present in graphite and then dumps the transformed polyhedral structures into a scop file. Graphite will then read the generated file and proceed to code generation through Gloog “scop_to_clast()”.
The current internal scop representation in graphite is actually different from the simple scopLib format. In graphite, a scop is formed of a vector of polyhedral basic blocks (poly_bb or pbb for short), each pbb has its own scattering function, iteration domain, and a vector of polyhedral data references (poly_dr_p) that describe read and write accesses.
ScopLib has the same general structure, but differs in some internal details from the graphite polyhedral representation, in this section, we present a list of differences between scopLib format and the internal Graphite format :
- Statement representation : different between Graphite and scopLib, but as the statements section in a scop file is not needed by Pluto to perform loop transformations, it will be ignored for now and not considered as a priority,
- Iteration domain : exactly the same between Graphite and scopLib,
- Scattering functions : Graphite uses full scattering relations represented as union of polyhedron whereas in scoplib the scattering function is a set of affine functions that does not consider union of polyhedron. We will use the extended scopLib format to handle these differences (the extended scopLib is an extension that supports scattering relations, union of scattering polyhedrons...),
- Data accesses : data accesses in graphite are represented as relations, scopLib represent accesses as functions, we will use the extended scopLib format to be able to represent graphite data accesses,
- Data dependencies : polyhedral tools need data dependencies information to perform optimizations, in a first step, data dependencies will not be exported from Graphite, they will be calculated by the tool itself (Pluto will call candl to extract data dependencies and insert them into the .scop file).