Application of a piecewise quasi-affine transformation to a band node

Dear Sven,

if I'm not mistaken, according to our discussion on,
application of a piecewise quasi-affine transformation to a band node
isn't available yet in the public repo, because there are open
questions about design decisions.

Could you please advise me where I can find it's current
implementation and information about these open questions?

I'm attaching what I managed to dig out.
It's a preliminary patch that is not ready for inclusion,
but you can check if the interface looks like it might work
for you.

There are still several issues to resolve.

One issue is what to do with anchored trees.
The elements in the subtree that refer to the original
band need to be modified as well to refer to the modified band.
If the transformation is injective, then it is always possible
to compute the required left-inverse that is needed to transform
those elements.
One question is whether this left-inverse should indeed be computed
by isl_schedule_band_band_transform_pw_multi_aff or whether it should
be speficied by the user. The user may have easy access
to a simple form of the inverse.
If the user is allowed to specify an inverse, then this could
also be done in cases where the transformation is not injective.
It's not clear if there are any use-cases for that, though.
In fact, it's not even clear if you would ever want to transform
a band node with an anchored subtree in the first place.
The attached patch completely ignores this issue,
but this should obviously be fixed first.

Another issue is what to do with properties such as
permutability and coincidence. The attached patch
simply clears all properties. For some special cases
of transformations such as permutations, it would be
possible to transform the properties accordingly,
but I don't think it's possible in general.

Since isl_schedule_band_band_transform_pw_multi_aff accepts
a piecewise affine transformation, it is possible that
the transformation _removes_ some parts of the domain.
I think this should not be allowed, meaning that
isl_schedule_band_band_transform_pw_multi_aff would have
to check this condition. An alternative would be
to introduce an isl_schedule_band_band_transform_multi_aff
instead, which would not have to worry about this issue.

Thank you for the detailed explanation and the patch! I'll try to
understand whether there are use-cases that could cause these issues
in our case.