MLIR failure error when using DenseHashTable
in tf.map_fun
#2246
Labels
stale
This label marks the issue/pr stale - to be closed automatically if no activity
stat:awaiting response
System information
tensorflow/serving:2.11.0
Describe the problem
When TFS starts up serving a model with the code described below in the model signature, we observe this message when Grappler runs before TFS is finally initialised:
Source code / logs
In the code below, a DenseHashTable is generated on every
Predict
request from an N-element string Tensor,sorted_list
, the keys, and values simply the index of the entry. Also on every request,rails_to_sort
is a 2D RaggedTensor of type string.rails_to_sort
is passed to amap_fn
which iterates the rows. The mapped function,reorder_rail
, looks up the row against thesorted_list
DenseHashTable to find the indexes of match positions, then sorts the row according to matches. The output is the sorted version of the input RaggedTensor.The problem is not related to the sort itself.
The following
tf.function
is part of the concrete function traced on the model's serving signature:The graph node generated for the
map_fn
swhile
loop is as follows:The error message refers to argument 6,
MutableDenseHashTable:table_handle:0
, and of course it is'tensor<!tf_type.resource<tensor<!tf_type.string>, tensor<i32>>>'
as we have initialised it withstring
keys andint32
values. But Grappler seems to think it should be'tensor<!tf_type.resource<tensor<!tf_type.string>>>'
.The error does not seem to affect the functionality of the graph, ie. it works as intended in unit tests and when served with TFS 'live'.
We would like to be re-assured that the error will have no functional impact, but also to understand if this failure is affecting graph optimization, ie. does this failure stop optimization, so we are losing potential performance gains?
The text was updated successfully, but these errors were encountered: