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
Running the test case in ops/eltwise_mult_CSRxDense_oCSR.ta unveils a bug in the IR that is hard to notice since it does not affect the results.
Specifically, lowering to loops (--emit-loops) produces the following IR:
SSA %11, which refers to data related to one of the input sparse tensors is printed when I try to print the result/output tensor. This means that the input and output tensors share a reference to the same data structure which should not be the case.
Even worse, SSA %17#1 is a tensor produced by tensor.insert into one of the underlying data of the same input tensor. this operation specifically: %inserted_26 = tensor.insert %extracted_23 into %arg6[%arg5] : tensor<?xindex>.
I have formatted the related pieces of IR in bold to make it easier to track what I'm referring to.
The problem does not show up since we never check the input tensors but, also, one-shot-bufferize saves us by creating copy a of the tensor that we try to insert to before inserting to it.
If I let bufferization happen, here it is what we get (--convert-ta-to-it --convert-to-loops)
I don't think the issue described above is accurate. %11 and %12 are coordinate tensors. When inferring the domain of the output tensor, we recognize that it is the same as the input tensor, therefore we use the same coordinate tensors. Because we are ensured SSA semantics with tensors, this will always be safe. If at a later point we want to modify the coordinates, we are guaranteed to create a copy of the tensor (as happens to %12 here).
I think the (smaller) issue is that we are doing too much inserting. We recognize that we can use the same coordinate tensors, but then we insert the coordinates anyway (%inserted_26). Note that this is only a performance issue and will always produce the correct results. This happens as a result of the ta.TensorInsertOp lowering where we assume we must insert a coordinate with the float value. At some point in the lowering process, we should detect which coordinate tensors need a value inserted. This will also be crucial to support other sparse output formats.
Running the test case in
ops/eltwise_mult_CSRxDense_oCSR.ta
unveils a bug in the IR that is hard to notice since it does not affect the results.Specifically, lowering to loops (
--emit-loops
) produces the following IR:Here, we can see two issues:
%11
, which refers to data related to one of the input sparse tensors is printed when I try to print the result/output tensor. This means that the input and output tensors share a reference to the same data structure which should not be the case.%17#1
is a tensor produced bytensor.insert
into one of the underlying data of the same input tensor. this operation specifically:%inserted_26 = tensor.insert %extracted_23 into %arg6[%arg5] : tensor<?xindex>
.I have formatted the related pieces of IR in bold to make it easier to track what I'm referring to.
The problem does not show up since we never check the input tensors but, also, one-shot-bufferize saves us by creating copy a of the tensor that we try to insert to before inserting to it.
If I let bufferization happen, here it is what we get (
--convert-ta-to-it --convert-to-loops
)Notice the copy operation that is inserted in bold. However, we cannot rely on this.
The text was updated successfully, but these errors were encountered: