Update the TensorInfo protobuf message with an encoding for composite tensors; and update SavedModel to use this new encoding.

PiperOrigin-RevId: 262639435

PiperOrigin-RevId: 262639287

PiperOrigin-RevId: 262639009

Currently, GrpcServer does not support clean shutdown and destruction after GrpcServer::Start() is called, and logs a FATAL error in this case. In UpdateTFE_ContextWithServerDef(), there are several cases where a method can fail (e.g. due to invalid user input), and we attempt to destroy the created GrpcServer before returning. By deferring the call to GrpcServer::Start(), we can return an error to the client without crashing their process.

PiperOrigin-RevId: 262638388

export enable_tensor_equality disable_tensor_equality so that users have way to opt-in and opt-out explicitly

PiperOrigin-RevId: 262637047

PiperOrigin-RevId: 262631581

PiperOrigin-RevId: 262630016

PiperOrigin-RevId: 262628782

This will let the training function to return the correct number of examples to the callbacks.

PiperOrigin-RevId: 262623679

PiperOrigin-RevId: 262622407

PiperOrigin-RevId: 262615881

PiperOrigin-RevId: 262613092

These tests are both failing for unknown reasons on Windows, so we are disabling them until we can figure out the issue.

PiperOrigin-RevId: 262610531

PiperOrigin-RevId: 262603945

PiperOrigin-RevId: 262603680

I fixed the examples so they actually can run now. And I mentioned that currently, only the first argument to call() is casted.

PiperOrigin-RevId: 262603558

PiperOrigin-RevId: 262603535

This also fix a crash in `condFn.getType()` if the lookupSymbol fails.

PiperOrigin-RevId: 262599229

We have observed that the tfl.mul folder couldn't fold the two operands even
they are broadcast-compatible. Since we can guarantee the tf.Mul kernel can
fold this, we switch to use tf.Mul instead.

PiperOrigin-RevId: 262598998

Fixed #27305.

PiperOrigin-RevId: 262592130

The translation code predates the introduction of LogicalResult and was relying
on the obsolete LLVM convention of returning false on success.  Change it to
use MLIR's LogicalResult abstraction instead. NFC.

PiperOrigin-RevId: 262589432

This avoids recalculating instruction count in a hlo module per
computation, which is a non-trivial overhead if the model is big.

PiperOrigin-RevId: 262589426

PiperOrigin-RevId: 262588769

The tf.function approach does not work well in v1 with session since it might try to update /mutate the graph between session. This change will disable the tf function path in v1 session mode. This will prevent any user to use cudnn kernel either with compat.v2 or tf.disable_eager_exeuction().

Note the estimator in v2 should still have the graph rewrite support (have cudnn kernel on GPU).

The graph rewrite tests are now run in v2 only since the rewrite in v1 has been disabled.

PiperOrigin-RevId: 262577530

platforms.

PiperOrigin-RevId: 262574960

PiperOrigin-RevId: 262571387

Unlike regular constant values, strings must be placed in some memory and
referred to through a pointer to that memory.  Until now, they were not
supported in function-local constant declarations with `llvm.constant`.
Introduce support for global strings using `llvm.global`, which would translate
them into global arrays in LLVM IR and thus make sure they have some memory
allocated for storage.

PiperOrigin-RevId: 262569316

In the underflow case of QuantizeMultiplier, when an exponent smaller than -31 would be produced, which would mean that the corresponding right-shifts would always produce zero anyway but would require additional code to handle
there as right-shift instructions may not handle shift amounts greater than 31, let us just round the multiplier to 0, producing a quantized multiplier with a fixed-point component 0, similar to what we have been doing when the incoming real multiplier is exactly 0.

This case has occurred in a graph where fakequant-learned ranges were of the form [0, 1e-26]. Such an array effectively contains only zero, but the learning process has not exactly converged on that yet.

PiperOrigin-RevId: 262566586

Rewrite the handling of threads==1, so it's a little more readable, and gets compiled with -O3 in a way that puts this case at the start of the function instead of at the end, which for a mysterious reason results in more stable performance.

PiperOrigin-RevId: 262565366

Add support for translating recently introduced llvm.global operations to
global variables in the LLVM IR proper.

PiperOrigin-RevId: 262564700

PiperOrigin-RevId: 262564534

See the comment.

PiperOrigin-RevId: 262564280

Also, minor cleanup of methods.

PiperOrigin-RevId: 262564087

PiperOrigin-RevId: 262562281

PiperOrigin-RevId: 262558564

This CL introduces the ability to generate the external library name for Linalg operations.
The problem is that neither mlir or C support overloading and we want a simplified form of name mangling that is still reasonable to read.
This CL creates the name of the external call that Linalg expects from the operation name and the type of its arguments.

The interface library names are updated and use new cases are added for FillOp.

PiperOrigin-RevId: 262556833

This CL adds the ability for linalg.view to act as a bitcast operation.
This will be used when promoting views into faster memory and casting to vector types.

In the process, linalg.view is moved to ODS.

PiperOrigin-RevId: 262556246

This CL is step 2/n towards building a simple, programmable and portable vector abstraction in MLIR that can go all the way down to generating assembly vector code via LLVM's opt and llc tools.

This CL adds the vector.outerproduct operation to the MLIR vector dialect as well as the appropriate roundtrip test. Lowering to LLVM will occur in the following CL.

PiperOrigin-RevId: 262552027

PiperOrigin-RevId: 262551455

PiperOrigin-RevId: 262550835