[Executor] Restore (inaccurate) "iter_num" trace metadata in `ExecutorState::Process()`.

Note that different kernels executed during a single call to `Process()` could have different iteration numbers, and this information will be lost. However, this change restores the previous behavior, which some tests rely on.

PiperOrigin-RevId: 304444520
Change-Id: Ia81b7152553aadcebbebe0172a8974197a7696c6

tensorflow/core/common_runtime/executor.cc

@@ -625,7 +625,14 @@ template <class PropagatorStateType>
 void ExecutorState<PropagatorStateType>::Process(TaggedNode tagged_node,
                                                  int64 scheduled_nsec) {
   profiler::TraceMe activity(
-      [&] { return absl::StrCat("ExecutorState::Process#id=", step_id_, "#"); },
+      [&] {
+        // NOTE: This tracing uses the iteration number from the first tagged
+        // node that executes during this call to `Process()`. In principle,
+        // subsequent nodes could have different values of `iter_num` that
+        // will not be traced.
+        return absl::StrCat("ExecutorState::Process#id=", step_id_,
+                            ",iter_num=", tagged_node.get_iter_num(), "#");
+      },
       2);
   WithContext wc(context_);
   TaggedNodeSeq ready;

tensorflow/core/common_runtime/propagator_state.h

@@ -74,6 +74,7 @@ class PropagatorState {
     const NodeItem& get_node_item() const { return *node_item; }
 
     bool get_is_dead() const { return is_dead; }
+    int64 get_iter_num() const { return input_iter; }
   };
 
   // A drop-in replacement for std::deque<TaggedNode>.  We typically don't