by Riccardo Mori

Description

Polly is a project written in C++ but internally it uses isl (Integer Set Library) which is a library written in C. Isl uses reference-counting for memory management but that makes the code more error-prone and in general it is harder to use, so the Polly developers made a custom C++ interface that aims to use C++ RAII to handle the reference counting thus making it easier to use the library.

Since then isl also gained an official C++ interface and I intend to switch from the Polly-maintained one (isl-noexceptions.h) to the upstream one (cpp.h or cpp-checked.h). Unfortunately, this is not an in-place replacement, differences include how errors are checked, method names, which functions are considered as operator/constructor overloads and the set of exported functions.

Even though the final goal would be to fully replace the bindings it is probably out of reach of the scope of this GSoC since the number of exported functions and classes in isl-noexceptions.h exceeds the ones exported in the official interface. Still, I expect to at least reduce the differences between the twos and as a result reduce the maintenance cost of isl-noexceptions.h.

Moreover Polly in some places still uses the isl standard C API so it is also nice to refactor that code to use the C++ bindings.

My contribution

Refactoring Polly to use C++ bindings

D99841 “Refactoring isInnermost() from isl to use the C++ wrapper”

D99971 “Partially refactoring of IslAstInfo and IslNodeBuilder to use isl++”

D100265 “Partial refactoring of IslAst and IslAstInfo to use isl++. NFC.”

D104370 “Refactoring IslAstInfo::getBuild() and IslAstInfo::IslAstUserPayload::Build to use isl++. NFC”

All these patches refactor some code to make use of the custom C++ bindings for isl instead of the previously used C API. This is nice because by using the Resource Acquisition Is Initialization (RAII) paradigm of C++ it is easier to handle the isl objects and we can just focus on the Polly code.

Reducing the differences between the custom and the official C++ interface

D103751 “Removing nullptr constructor from C++ bindings. NFC.”

D103976 “Removing explicit operator bool() from isl C++ bindings. NFC.”

In the official isl interface every isl::boolean must be checked for errors so that’s why there is no explicit operator bool().

D104211 “Replacing isl method to_str() with stringFromIslObj(). NFC.”

Since the only way to get a string representation for an isl C++ object is through its ostream operator << I implemented a new method stringFromIslObj() that returns the string representation of an isl object.

D104994 “Use isl::set::tuple_dim, isl::map::domain_tuple_dim and isl::map::range_tuple_dim. NFC”

This is in conjunction with the following commit. Since the official interface doesn’t export the isl_dim type there was a need to add a function to get the dimensionality of a isl::map or a isl::set. After a discussion in the isl-dev mailing list the functions were upstreamed and we were able to use them.

D105444 “Use isl::union_set::unite() instead of isl::union_set::add_set(). NFC”

D105691 “Use isl::*::ctx instead of isl::*::get_ctx. NFC”

D106059 “Stop generating isl::union_{set,map} from isl::space. NFC”

The correct way to generate a isl::union_set or a isl::union_map is from a isl::ctx. The function for generating such objects from a isl::space was not intended to be exported in the C++ interface.

D106061 “Use isl::union_map::unite() instead of isl::union_map::add_map(). NFC”

D106269 “Stop using isl::set::lex_le_set. NFC”

The functionality was recreated through the more general function isl::set::lex_le_at.

D107225 “Move to the new-polly-generator branch version of isl-noexceptions.h. NFCI”

This is the biggest change. I recreated the custom isl interface that was used by Polly starting from the master branch of the official one. I exported all the functions that are used by Polly one by one so it’s easier to remove each one of them, this will make things easier for the future work that I intend to do. During this process I also had to switch from cpp.h to cpp-checked.h as a base starting point for our custom interface since we needed some classes that were not exported in cpp.h.

The new interface can be found here.

D107293 “Use isl::val::sub instead of isl::val::sub_ui. NFC”

Isl patches

These are the patches that I pushed to the isl repository.

Exporting isl_union_set_get_set_list

e646076e eb9659da d7be01f7

Exporting isl_set_n_basic_set and isl_map_n_basic_map

fcf9a732 54aac5a


The new C++ interface that is the final result can be found here.

Here you can find a list of the differences with the official interface that still remains. I intend to continue working on this project in the future so the list is up to changes.

Conclusion

As initially stated I wasn’t able to completely switch from the (erase all the differences from the) custom interface to the official one since there were too many exported functions (around 200 right now) that aren’t present in the official interface and a lot of effort is needed to discuss on the isl-development mailing list about which of them can be upstreamed and for which of them there is a valid alternative that can be used before reimplementing them in Polly.

Nevertheless I was able to reduce the number of differences between the twos and by recreating the Polly interface starting from the official one I was able to significantly reduce the effort needed in maintaining it. It is also a lot easier now to know which functions that are used by Polly aren’t present in the official interface and that would make things easier for the future work that I intend to do. That represents the biggest impact of my work for this GSoC.

Future work

As previously said there are still some differences that needs to be eliminated in order to be able to drop the custom interface. Particularly difficult will be dealing with all the functions that take a isl::dim parameter because as Sven Verdoolaege, the author of isl, said in the mailing list the isl_dim type won’t be exported and that means having to find a specific solution for each of those functions.

Anyway I intend to continue working on that and proceed to reducing the differences one by one.