%5 = "tf.Identity"(%4) {__op_key = 10: i32, device = "/device:CPU:0"} : (tensor<!tf_type.variant>) -> tensor<!tf_type.variant>
  func.return %5 : tensor<!tf_type.variant>
}
// CHECK-LABEL: __inference_Dataset_map_lambda_160

    %9 = "tf.opK"(%input_0, %input_4, %9) :
      (tensor<i32>, tensor<!tf_type.variant>, tensor<i1>) -> tensor<i32>
    tf_device.return %9 : tensor<i32>
  }) {device = "DEVICE_ALIAS_0"} : () -> tensor<i32>
  %l = "tf_device.launch"() ( {
    %10 = "tf.opL"(%input_1, %input_4, %9) :
      (tensor<f32>, tensor<!tf_type.variant>, tensor<i1>) -> tensor<f32>
    tf_device.return %10 : tensor<f32>

        "composite" tensors, such as `tf.RaggedTensor`, as inputs.
    *   Fix device placement issues related to datasets with ragged tensors of
        strings (i.e. variant encoded data with types not supported on GPU).
    *   'experimental_follow_type_hints' for tf.function has been deprecated.
        Please use input_signature or reduce_retracing to minimize retracing.

  INT16 = 7,
  COMPLEX64 = 8,
  INT8 = 9,
  FLOAT64 = 10,
  COMPLEX128 = 11,
  UINT64 = 12,
  // Experimental: Resource and variant types are experimental, that are subject
  // to change. Do not implement custom kernels using resource & variant types
  // now.
  RESOURCE = 13,
  VARIANT = 14,
  UINT32 = 15,
  UINT16 = 16,
  INT4 = 17,
  BFLOAT16 = 18,
}

  INT16 = 7,
  COMPLEX64 = 8,
  INT8 = 9,
  FLOAT64 = 10,
  COMPLEX128 = 11,
  UINT64 = 12,
  // Experimental: Resource and variant types are experimental, that are subject
  // to change. Do not implement custom kernels using resource & variant types
  // now.
  RESOURCE = 13,
  VARIANT = 14,
  UINT32 = 15,
}

// Custom quantization parameters for experimenting with new quantization
// techniques.

  %1 = "tf.TensorListGetItem"(%0, %arg2, %arg1) {device = "/job:localhost/replica:0/task:0/device:GPU:0"} : (tensor<!tf_type.variant<tensor<1x32xf32>>>, tensor<i32>, tensor<2xi32>) -> tensor<1x32xf32>

  %zeros-like = "tf.ZerosLike"(%addn) : (tensor<!tf_type.variant<tensor<f32>>>) -> tensor<!tf_type.variant<tensor<f32>>>
  // CHECK-NEXT: %[[ADDN2:.*]] = "tf.AddN"(%[[ADDN]], %[[ZEROS_LIKE]]) : (tensor<10xf32>, tensor<10xf32>) -> tensor<10xf32>
  %addn2 = "tf.AddN"(%addn, %zeros-like) : (tensor<!tf_type.variant<tensor<f32>>>, tensor<!tf_type.variant<tensor<f32>>>) -> tensor<!tf_type.variant<tensor<f32>>>

  %0 = "tf.TensorListLength"(%arg1) : (tensor<!tf_type.variant>) -> tensor<i32>
  %1 = "tf.Identity"(%arg1) : (tensor<!tf_type.variant>) -> tensor<!tf_type.variant>
  func.return %0, %1 : tensor<i32>, tensor<!tf_type.variant>

// verify `body` function's signature.
// CHECK: func @tensorlistWhileBody(%[[ARG0:.*]]: tensor<i32>, %[[ARG:.*]]: tensor<2x3xf32>) -> (tensor<i32>, tensor<2x3xf32>)
// CHECK-NOT: tensor<!tf_type.variant>

      metadata = ""} : (
              tensor<4xf32>,
              tensor<3xf32>,
              tensor<!tf_type.resource>,
              tensor<2xf32>) -> tensor<!tf_type.variant>
  return %0 : tensor<!tf_type.variant>

Creates a dataset that invokes its 'next' region to generate elements. Conceptually,
within MLIR, we treat this op as if it fills a buffer with all the results right away,
and those results are then passed (through the variant tensor result) to
MakeIterator / IteratorGetNext. Note that the actual TF implementation differs: It
generates the next element just in time, during IteratorGetNext.

init_extra_args: Additional arguments to pass to 'init'.