[llvm-dev] [isl-dev] Application of a piecewise quasi-affine transformation to a band node
Roman Gareev via llvm-dev
llvm-dev at lists.llvm.org
Sat Jun 25 07:08:35 PDT 2016
> 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.
More information about the llvm-dev