…cLayoutOptimizer.

PiperOrigin-RevId: 258198838

PiperOrigin-RevId: 258198866

PiperOrigin-RevId: 258199464

PiperOrigin-RevId: 258199946

  Sum_{i=1,...,k} Precision@i(e) * I(i, e) / D(k, e)
where I(i, e) is 1 if label of rank i for e is a positive label for e, and 0 otherwise,
and the denominator D(k, e) is the maximum possible number of terms in the sum with a non-zero I(i, e): D(k, e) = min(k, number positive labels for e).

While this formula is implemented correctly in `average_precision_at_k` when `labels` is a sparse tensor, it is incorrect when `labels` is a dense tensor with some values out of range [0, num_classes), necessary in the case of examples with a different number of positive labels. In this case, the current implementation defines the denominator as
D(k, e) = min(k, size of last dimension of `labels`).

Consider 2 examples e_1 and e_2 with positive labels {0, 1} and {0}, assume that the top ranked label for e_2 is 0. AveragePrecision@2(e_2) = 1 and is computed correctly when the labels are given by a sparse tensor, but when the labels are given by a dense tensor, e.g. [[0, 1], [0, -1]], then AveragePrecision@2(e_2) = 0.5, as D(i, e_2) is considered min(2, 2).

This CL corrects this error.

PiperOrigin-RevId: 258200333

…rces.

PiperOrigin-RevId: 258201156

…n data edge" for If/While nodes as well.

PiperOrigin-RevId: 258205803

This change also adds a test that covers the error, i.e. attempting to pass in
tensors with different shapes across runs to a particular instance of a
collective gather op.

PiperOrigin-RevId: 258207891

PiperOrigin-RevId: 258208153

…h op for rebatching.

PiperOrigin-RevId: 258211187

PiperOrigin-RevId: 258216008

…en loading, and vice versa.

Support for this was (perhaps unintentially) added in cl/242345741.

PiperOrigin-RevId: 258218701

PiperOrigin-RevId: 258222061

PiperOrigin-RevId: 258225869

This will make the code correctly fallback to use existing train_array
or train_generator.

PiperOrigin-RevId: 258227722

…ef to MLIR

Otherwise, it will fail to find the input node later in InferMainFunctionType method. We should preserve input nodes even if unused so that user can feed inputs, as specified.

PiperOrigin-RevId: 258230459

PiperOrigin-RevId: 258233713

This update fixes few TensorChipping and TensorSlicing regressions.

PiperOrigin-RevId: 258238409

PiperOrigin-RevId: 258239245

PiperOrigin-RevId: 258242570

…tfrun_removal

PiperOrigin-RevId: 258244067

…from bazelrc file

They are no longer needed and will prevent future incompatible migration for RBE build.

Related bazelbuild/bazel#7480

PiperOrigin-RevId: 258244467

PiperOrigin-RevId: 258246018

Note that this must always be used in conjunction with
`--post_training_quantize` to have any effect in conversion.

PiperOrigin-RevId: 258246075

PiperOrigin-RevId: 258246204

…string

PiperOrigin-RevId: 258248081

…cond-order gradients where we weren't before cl/256268751

A better fix would be to temporarily pop all existing tapes (not pause all tapes globally), then restore them when we're done building the function. But that needs a bit more infrastructure.

PiperOrigin-RevId: 258250440

…tead of calling importlib.

We saw issues with tensorflow_estimator that getattr was called on a module before the module finishing running. Switching back to standard import statements.

Keeping the module wrapper so we don't need to revert the changes made to templated __init__.py in cl/257240535.

PiperOrigin-RevId: 258251871

…nto the outside_compilation region.

PiperOrigin-RevId: 258254009

PiperOrigin-RevId: 258254040

…her instances.

We frequently waste memory during graph construction and optimization by copying FunctionLibraryDefinition objects, which entails a copy of all the FunctionDefs in the library. Since all FunctionDefs (and related op registration data) in the library are immutable after it is constructed, we can share them with other library instances.

PiperOrigin-RevId: 258254464

PiperOrigin-RevId: 258254881

PiperOrigin-RevId: 258256417

…his doesn't ensure any determinism or ordering. This is especially useful when the data is compressed because the decompression code can be quite intensive and its very helpful to parallelize it.

PiperOrigin-RevId: 258259309

PiperOrigin-RevId: 258261110

…y replacing absl::flat_hash_set with std::set.

PiperOrigin-RevId: 258261287

PiperOrigin-RevId: 258263420

PiperOrigin-RevId: 2582635

PiperOrigin-RevId: 258264512

Failed tests are all disabled for now, and we should address them while we updating the v2 training path and util functions.

PiperOrigin-RevId: 258267130

The strategy to always dump FileCheck input generates a large amount of log spam, and makes debugging other failures difficult.
We only need the full input if the test has failed.

PiperOrigin-RevId: 258267702

PiperOrigin-RevId: 258267779

Fixes: tensorflow#29989
PiperOrigin-RevId: 258269050

PiperOrigin-RevId: 258271243

PiperOrigin-RevId: 258271679

Since Sequential has its own layer tracking logic, disable the tracking logic in base_layer setattr for sequential models.

PiperOrigin-RevId: 258275046

PiperOrigin-RevId: 258275394

PiperOrigin-RevId: 258275543

…d_mkldnnv0.20

PiperOrigin-RevId: 258277683

PiperOrigin-RevId: 258284211

With some combinations of compiler options (though surprisingly not just enabling ASAN), taking the address of the first member through a null `std::shared_ptr<FunctionDefAndOpRegistration>` fails.

PiperOrigin-RevId: 258295758

…::array.

The registry is keyed by an enum and contains a static number of keys (based on an enum), so this avoids a map lookup at the start of every eager op execution.

PiperOrigin-RevId: 258296647

PiperOrigin-RevId: 258304540

…E tests

When the graph debug info is generated by TensorFlow, the node stack trace is
indexed by the string concatenation of function name and node name, so we have
to use the same string to lookup the stack trace for the nodes.

E2E tests for displaying stack traces in the error messages are added to verify
the stack traces for nodes from both graphs and functions can be displayed
correctly.

PiperOrigin-RevId: 258311493

PiperOrigin-RevId: 258313758

…mark tool.

PiperOrigin-RevId: 258317482

PiperOrigin-RevId: 258324381

PiperOrigin-RevId: 258324385

The skeleton returns unimplemented for all members of the Compiler
interface. It can only be used when combined with the FailoverCompiler
and the existing GPU backend. This is also the configuration that is
registered.

PiperOrigin-RevId: 258333034

…upstream_avgpooling_op_part_two

PiperOrigin-RevId: 258349112

…upstream_einsum_op

PiperOrigin-RevId: 258349270

…sible().

PiperOrigin-RevId: 258349333

…upstream_stateful_random_ops

PiperOrigin-RevId: 258349360

…ns passes.

For now, the MLIR backend will expect the same HLO as input as the GPU backend
does. Hence, we need to run the same required passes. Also use the same HLO
level optimizations, so that we get comparable HLO.

PiperOrigin-RevId: 258349785

…t (v2). This ensures we can print to these streams without needing to use tf.compat.v1

PiperOrigin-RevId: 258360763

Think v2 Variables are resource Variables so `use_resource=True`
is not relevant any more (and there is no `use_resource` arg in __init__).

Signed-off-by: Yong Tang <[email protected]>

PiperOrigin-RevId: 258361644

…trib_gan_examples

PiperOrigin-RevId: 258371737

#defines - they were tested directly by #ifdef, and were being defined
by path.h.  As tune.cc did not #include path.h, it did not enable its
platform-specific tuning code, resulting in a performance regression
in cases relying on tuning for maximal performance --- in-order ARM.

To prevent that from happening again, this moves the platform defines
to a new platform.h and forces users to use a RUY_PLATFORM(X) function
macro, so that if they fail to #include platform.h, they get a compilation
error.

PiperOrigin-RevId: 258372624

PiperOrigin-RevId: 258373033

Dataset elements are no longer limited to nested structures of Tensors. This change updates the docs to refer to "dataset elements" instead of nested structures of Tensors.

We may want to also deprecate from_tensors/from_tensor_slices and replace them with better-named from_element/from_element_slices. Since this is more controversial, we can do it as a separate change.

PiperOrigin-RevId: 258375042

This slightly speeds up the common case of converting shape lists to
tensors (when calling an op).

Before:

>>> %timeit tf.convert_to_tensor([1, 2, 3])
100000 loops, best of 3: 10.4 ?s per loop
>>> %timeit tf.convert_to_tensor(np.array([1, 2, 3]))  # For reference.
100000 loops, best of 3: 6.47 ?s per loop

After:

>>> %timeit tf.convert_to_tensor([1, 2, 3])
100000 loops, best of 3: 7.23 ?s per loop

The remaining 1us is due to the necessary nest.flatten call. It might
be optimized by introducing nest.all which does not allocate a flat
list.

PiperOrigin-RevId: 258375416

…on some Android P devices.

PiperOrigin-RevId: 258378187

PiperOrigin-RevId: 258380926

PiperOrigin-RevId: 258385606

50001.

PiperOrigin-RevId: 258389320

PiperOrigin-RevId: 258389587

PiperOrigin-RevId: 258391933

PiperOrigin-RevId: 258392805

PiperOrigin-RevId: 258393073

This patch contains various changes to allow the worflow working for both UINT8
and INT8 quantization scheme:

- The "restricted_output_params" in the "OpQuantSpec" is changed to a map, so
  the op definition can define restrictions for both UINT8 and INT8.

- INT8 quantization spec is added to the TFLite op definition.

- a "quantize_sign" flag is passed into the pre-quantize pass, so the spec and
  propgation for different sign can be configured by this flag.

There are followup patches to read this flag from the user's command line.

PiperOrigin-RevId: 258393145

A missing comma in a list of string means the string "Rank" and "ShapeN" will be concatenated implicitly.

PiperOrigin-RevId: 258395114

…base class)

PiperOrigin-RevId: 258399687

PiperOrigin-RevId: 258404510

…vars.

It would fail on ndarrays with an numpy.dtype doesn't have is_floating check on the next line in any case, so this gives it a nicer error message.

Also use the common RegisterType functionality to check for resource variables.

PiperOrigin-RevId: 258407797

PiperOrigin-RevId: 258412619

PiperOrigin-RevId: 258413874

…rg, but

this doesn't make sense for matvec (and isn't in the base class matvec defn).
PiperOrigin-RevId: 258417922

PiperOrigin-RevId: 258422018

this is the preparation to merge the internal xprof and external oss version of annotation implementation, I need to make sure the benchmark is comparable or better.

PiperOrigin-RevId: 258425457

… complication. This code didn't know whether it wanted to hide latency of an atomic increment (60 cycles) or of a block coords computation (comparable). Now it's more intentional about hiding the atomic increment latency, because that's the one instruction here that will always have high latency; for the rest, we can only hope that the compiler will exploit any opportunity to inline the block computation and distribute its instructions so as to hide some of the latency.

The more important point is what while we don't really know what would run faster and that will at most make a small impact on latency, on the other hand there is a substantial code simplification here, and this matters because this is very central code. Notice in particular how the block coords computation was written twice, once before the loop body and one at the end of the loop body, and now it's only once anymore.

PiperOrigin-RevId: 258429272