[WIP] use templated isl types

[skimo-openhub]

Templated isl types require the user to specify the domain and range universes of isl objects, allowing the compiler to check whether it makes sense to combine pairs of objects. This RFC only converts isPromotableToRegistersBelow and some related functions to illustrate the effect. The isPromotableToRegistersBelow was already applying operations correctly, so the code itself did not require any changes. However, one variable was reused to store different types of intermediate result and this one had to be split up into several variables because they now have different types.

[nicolasvasilache]

From a quick glance, this looks great to me

[skimo-openhub]

On Fri, Jun 22, 2018 at 04:52:38AM -0700, ftynse wrote:

Syntactic disambiguation. A particularly nasty interplay between templates and type inference. The syntax of a template is checked when parsing its definition. But type inference for auto is performed at template instantiation time. When parsing elemAs<detail::ScheduleTreeElemBand, the compiler wouldn't know if < is a comparison operator or the start of a template argument list. Unless elemAs is known to be a template (but it is not known because it's type has not been inferred yet when node is declared as auto), < is treated as a comparison operator. In this case, the RHS must be an expression. detail::ScheduleTreeElemBand>() is not a valid expression so the compiler complains. Adding the template prefix indicates that < must be always treated as the start of the template argument list, so it fixes the problem. So does manually specifying the type of node because the compiler now knows that elemAs is a function template.

Thanks. It makes sense now.

skimo

[ftynse]

I like the general idea. What worries me is the need to manually introduce member functions in the class templates. Those in isl bindings are autogenerated...

[skimo-openhub]

On Fri, Jun 29, 2018 at 05:50:56AM -0700, ftynse wrote:

I like the general idea. What worries me is the need to manually introduce member functions in the class templates. Those in isl bindings are autogenerated...

The idea would be for us to experiment with this for a while and if it turns out to be useful, we can think of autogenerating these functions too. Note that this would require some additional annotations.

skimo

[facebook-github-bot]

Thank you for your pull request. We require contributors to sign our Contributor License Agreement, and yours has expired.

Before we can review or merge your code, we need you to email [email protected] with your details so we can update your status.

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

[skimo-openhub]

On Fri, Jun 29, 2018 at 05:50:56AM -0700, ftynse wrote:

I like the general idea. What worries me is the need to manually introduce member functions in the class templates. Those in isl bindings are autogenerated...

I'm now generating these as well, but I'm still trying to pick the pieces apart, so it's not quite ready yet.

skimo

[skimo-openhub]

I got kicked out of the GitHub Facebook organization yesterday (before the end of my working day), so I can't update this PR. I created a new one instead (#604).