[Docs] Document some known TF/XLA limitations.

PiperOrigin-RevId: 313420872
Change-Id: I506c3115a807b64b7245a855ca01b55fd006b960

tensorflow/compiler/xla/g3doc/index.md

@@ -174,9 +174,33 @@ When filing bugs, attach the contents of the `/tmp/generated` directory
 
 If possible, try to isolate
 a bug to a single XLA program by using the
-[`replay_computation`](https://github.com/tensorflow/tensorflow/blob/master/tensorflow/compiler/xla/tools/replay_computation.cc)
+[`replay_computation`](https://github.com/tensorflow/tensorflow/blob/master/tensorflow/compiler/xla/tools/run_hlo_module_main.cc)
 and iteratively running it on generated programs.
 
+## Known Issues
+
+Compilation with XLA can greatly improve the performance of your programs, but
+the TensorFlow interop has a number of known sharp corners.
+
+### TensorArray TF/XLA Interconversion
+
+The problem manifests itself as an error message
+`Support for TensorList crossing the XLA/TF boundary is not implemented`.
+
+XLA supports `tf.TensorArray`. However, the _interconversion_ between TF and
+XLA representations is not implemented yet.
+This error often arises when the `TensorArray` is used inside the compiled
+block, but the derivative is taken outside.
+
+Workaround: compile the outermost scope which is taking the derivative.
+
+### Random Number Generation
+
+XLA currently ignores TF seeds to random operations. This affects stateful TF
+random operations, such as `tf.random.normal`, or `tf.nn.dropout`.  XLA will
+behave as if the compilation was seeded with a new unique seed at each run. This
+limitation does not apply to stateless random ops.
+
 ## XLA Frontends
 
 Apart from TensorFlow, XLA programs can be generated by: