You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue was not properly dealt with in previous versions. Since I'm currently doing the refactorization, we should have a comprehensive solution for that.
Background
A local variable will be introduced when dealing with semi-affine maps. For example, a code as follows:
%M will be a local variable for the domain of the internal affine.for resolved. The constraints around %N and %M can be derived from their floordiv 2 relation.
The access relation is derived from a AffineValueMap that we can get from MemRefAccess (ref). An AffineValueMap is an AffineMap together with a list of operands it applies. The issue of local variables is about these operands: we need to make sure every operand can be traced back to the values held by the domain, but a local variable is not there.
Specifically, given the code above, we can get a polyhedral statement as follows:
Because %1 (%M) is a symbol based on (isValidSymbol), we will directly pass it into @S0 in a form as %arg2. It will later become an operand of the AffineValueMap for the affine.store. That AffineValueMap would look like:
affine_map<()[s0, s1] -> (s0 + s1)>
and s0 and s1 will be replaced by %arg1 (%i) and %arg2 (%M). However, %arg2, or more specifically, %M, cannot be found in the domain we resolved. %M is a local variable, and a local variable is value-less (or internal, cannot find the correct wording) in the FlatAffineConstraints. Go back to the domain representation above (which is of type FlatAffineConstraints:
Before we dive into the solutions, there are several things from the Polymer design that cannot be broken:
A domain is immutable. Once we figure out what a domain looks like, especially what its dims and symbols are, we should not further alter it.
An access relation should not use values other than those in the domain, excluding local values. That is, if an access relation needs to use a value marked as local in the domain, it should instantiate again that value as a local one inside the access relation.
The statement interface should only include arrays, IVs, and parameters, e.g., including %M as an argument of @S0 in the previous example violates this rule. This is just a convention that can keep the design clean.
Our solution is:
In -extract-scop-stmt, we will only stop searching when seeing an operand that is included in the current domain constraints (as well as the global parameter set). Such that all the local variable calculation will be included internally to each callee.
When exporting OpenScop, we just build access constraints with all the affine.apply results flattened. This is done automatically, we just need to make sure that these affine constraints have the same columns as the domain (after merging with the context for their symbols) excluding all the local variables.
This issue was not properly dealt with in previous versions. Since I'm currently doing the refactorization, we should have a comprehensive solution for that.
Background
A local variable will be introduced when dealing with semi-affine maps. For example, a code as follows:
%M
will be a local variable for the domain of the internalaffine.for
resolved. The constraints around%N
and%M
can be derived from theirfloordiv 2
relation.And these constraints can be translated into a proper OpenScop relation.
l1
is%M
andP1
is%N
.The problem is around the access relation.
Getting the access relation
The access relation is derived from a
AffineValueMap
that we can get fromMemRefAccess
(ref). AnAffineValueMap
is anAffineMap
together with a list of operands it applies. The issue of local variables is about these operands: we need to make sure every operand can be traced back to the values held by the domain, but a local variable is not there.Specifically, given the code above, we can get a polyhedral statement as follows:
Because
%1
(%M
) is a symbol based on (isValidSymbol
), we will directly pass it into@S0
in a form as%arg2
. It will later become an operand of theAffineValueMap
for theaffine.store
. ThatAffineValueMap
would look like:and
s0
ands1
will be replaced by%arg1
(%i
) and%arg2
(%M
). However,%arg2
, or more specifically,%M
, cannot be found in the domain we resolved.%M
is a local variable, and a local variable is value-less (or internal, cannot find the correct wording) in theFlatAffineConstraints
. Go back to the domain representation above (which is of typeFlatAffineConstraints
:%M
is not actually stored in the domain.Solutions
Before we dive into the solutions, there are several things from the Polymer design that cannot be broken:
%M
as an argument of@S0
in the previous example violates this rule. This is just a convention that can keep the design clean.Our solution is:
-extract-scop-stmt
, we will only stop searching when seeing an operand that is included in the current domain constraints (as well as the global parameter set). Such that all the local variable calculation will be included internally to each callee.affine.apply
results flattened. This is done automatically, we just need to make sure that these affine constraints have the same columns as the domain (after merging with the context for their symbols) excluding all the local variables.Result
Given input code:
We will get:
The text was updated successfully, but these errors were encountered: