tensorflow / tensorflow

…ion is a tf.data operation.

PiperOrigin-RevId: 394474650
Change-Id: I2d0cdf2d2e7f0dffb452f6905382506484ea0b6e

* dtype and shape need to be properties.
* shape needs to return a sequence not an XLA shape.
* PyTpuBuffer needs to allow dynamic attributes to allow a .aval to be set.

PiperOrigin-RevId: 394453791
Change-Id: I1e3a907c8ddb4410e564b91d7a7080284df72cb9

…hon layer

PiperOrigin-RevId: 394420558
Change-Id: I7c6c7782f785d9f393daeb580d5ee2dc0de0e1e6

PiperOrigin-RevId: 394411061
Change-Id: Iccae00bbd2dc966a1b53ced4df5350ed6289b11a

PiperOrigin-RevId: 394410808
Change-Id: I370e1f0360360932d0d0da9c8f3994634192d588

PiperOrigin-RevId: 394409824
Change-Id: I129aeb2a4d2b955217bd677f71d9081c8902142a

…o tf.gather_nd:

* We will change the offset_dims to its canonicalized format and calculate its impact on the output layout
* Then insert a transpose op after the gather op

PiperOrigin-RevId: 394409744
Change-Id: Id065a796e1f4e8e57eac1bee84c165f17170e533

In particular, the mhlo.Iota fold supports the case when iota_dimension = last_dimension = output_rank-1. Additionally, the mhlo.BroadcastInDim fold supports the case where operand is a rank1 vector and the broadcast_dim = last_dim. We do not fold Iota or BroadCastInDim if the total number of elements is greater than 1024.

Also add a new case for MatchIota (folded 1d Iota + broadCastInDim).

PiperOrigin-RevId: 394399433
Change-Id: I5f56b214fc1786f64eb1210c5f6828aeb57b07bb

1. Add a note about potential differences in output tensor values.
2. Skip applying a delegate when the graph is already fully delegated.

PiperOrigin-RevId: 394395130
Change-Id: I5775f3e2b31dbaa53266ec318d01005ec09d2ce1

PiperOrigin-RevId: 394394351
Change-Id: Ie07389fd28e264bb82582ef3ba5dc7f90de584fa

PiperOrigin-RevId: 394393852
Change-Id: I0c3cd68d7ea03c298756853c35c14cca93180dee

…able. This also fixes an alloc-dealloc-mismatch issue detected by ASAN. An alternative fix is to use std::unique_ptr<const char*[]> instead of std::unique_ptr<const char*>.

PiperOrigin-RevId: 394384971
Change-Id: Ia0364244f98d226f5da57cc844a08271e2d9f551

In SharedMemoryUsage() and NumUnnestedReductions(), iterate over
fused_instructions_computation()->instructions() instead of
MakeInstructionsPostorder().

Making the postorder list is expensive, and in these cases we don't care about
the order of iteration.

This is a 1.5x speedup to HLO passes on the particular model I'm benchmarking.

PiperOrigin-RevId: 394383751
Change-Id: Ib762da86a91b7a4647e3cff836324c7b00c6c380

PiperOrigin-RevId: 394381858
Change-Id: I7f5d455fc83fdac283d1623caccf166f140d1640

…sors()

We should only call AllocateTensors() when input tensors are resized.

PiperOrigin-RevId: 394380926
Change-Id: I3be87b5037cc48b43276606cb39c53ea5b6177ef

It will save more runtime memory with very few latency overhead.

PiperOrigin-RevId: 394379825
Change-Id: I32e9d81ccc727687f7f7e4bdaa2de6d612de7fa8

…ocm_profiler

PiperOrigin-RevId: 394379474
Change-Id: I7870f38cb6474104e310b69ad2900317744e468e

PiperOrigin-RevId: 394378786
Change-Id: I50a6e64ef679c48abdae6deb5cf6cdd3e27dfbe7

PiperOrigin-RevId: 394378764
Change-Id: I54eaa3c00348ae27c90ea4bfde5b2909d1521e30

PiperOrigin-RevId: 394375319
Change-Id: If2811ab8ce3e508fba78648ad50b9ab9f1c3e81e

This makes the tfg. prefix optional in front of operations in their body
and the printed IR prettier.

PiperOrigin-RevId: 394373943
Change-Id: If3df6b76292b4ce0d4a77404d3438535402dbab6

PiperOrigin-RevId: 394369941
Change-Id: I5065bafd525cca16f562d08bc60dd5a20701711d

PiperOrigin-RevId: 394369251
Change-Id: Iaef22d5c121ddbea2fa16e7c95b35c3cd2708ec7

…he expected type (return void)

PiperOrigin-RevId: 394367438
Change-Id: I0116d8090e71fd28b987847d76c9eb90f58151b4

http://github.com/tensorflow/runtime/commit/bd539c47cd6dc71e8ce95c0f74712d903a3814d8.

PiperOrigin-RevId: 394359350
Change-Id: I51cc7f68e43029893fcb40bcd0c5b356d0f48acc

Updates LLVM usage to match
[eee687a66d76](llvm/llvm-project@eee687a)

PiperOrigin-RevId: 394358392
Change-Id: I0fa997513a5e516da04799f453b32891c93d4c91

PiperOrigin-RevId: 394353516
Change-Id: I5864a0a5743ef81022c625eca081f0a5050d0e06

PiperOrigin-RevId: 394338061
Change-Id: I394c18c400c5d2ef5714c3ba33b33fc5b3e8bd8f

PiperOrigin-RevId: 394305975
Change-Id: Ie4720a69adcf3933386877e967bf7de1528f5972

PiperOrigin-RevId: 394305289
Change-Id: I45b89e1250d11fd59de9a4e8081e4a5c9dd1b1cf

Updates LLVM usage to match
[9b6c8132d378](llvm/llvm-project@9b6c813)

PiperOrigin-RevId: 394303195
Change-Id: I4326ffb5843b000bd2e8589ace4aa55a6c98bcd9

…hape inference once. Thanks to Jacques Pienaar for suggesting this.

PiperOrigin-RevId: 394294762
Change-Id: Ic94bd5978d8327f5ca2f666f48bd57ab388b6038

PiperOrigin-RevId: 394287433
Change-Id: Ifebc7e1e4f04e3f9d5a5f14df4185824a4ed73af

The tuple index is written inside the consuming instruction as e.g.  "operand 1
= tuple-element 3 of fusion.42".

Alternative considered: My first attempt was to put the tuple element in the
edge label, which right now contains the operand index.  This didn't work well.
Graphviz doesn't prevent the edge label from overlapping with the edge itself
or anything else in the graph.  It was irredeemably messy.

PiperOrigin-RevId: 394286090
Change-Id: Ib6ea37aabe317eaf1adc71f359dc8bd89d040abc

…)` and `CreateGraphRewriteConfigs()`.

PiperOrigin-RevId: 394286052
Change-Id: I23e1c522bf24222d9c85461bd5f4621d8e39b844