Roman Gareev via llvm-dev
2016-Jun-25 14:08 UTC
[llvm-dev] [isl-dev] Application of a piecewise quasi-affine transformation to a band node
> 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. -- Cheers, Roman Gareev.