kumasento
commented
3 years ago This has been fixed in #87
The problem description is a bit wrong actually:
the thing we consider is like:
a = max(x, y)
for(i=10*a; i<n; i++) {}where a, as an operand to the loop bounds, is the result of max, which will be translated to affine.max and be rejected by the verifier.
The solution to this is basically we enclose that loop with a new function, and treat a as an argument. That would workaround with the problem by redirecting the usage of a to a top-level argument of an affine scope.
If a clast min/max expr is used in for bounds, Polymer will create an affine.min/max first, which will result in using values defined by affine.min/max as indvar. This is prohibited.
A workaround is, in this function:
https://github.com/kumasento/polymer/blob/187abcfc41da8d091438f7207ea339e2999b9115/lib/Target/OpenScop/ConvertFromOpenScop.cc#L1150-L1192
before we process the expr through the builder, we should first check if the type is a min/max reduction, and if so, process its operands individually and then use all of them as affine map results.
This might be tricky if there're nested min/max. Haven't seen that tho. Will ignore for now.
(P.S., this only appears after we propagate constants to the loop domain. Our previous successful results are still valid - in those cases the constants are still undecided.