The device field had outdated comments.

Note: We could consider adding tpu as an example here, e.g. "gpu" | "cpu" | "tpu".  Thoughts?

* Add int64 axis support for reduction ops.

This fix is a follow up to PR 13863. In PR 13863 the
program crash is fixed if int64 axis is passed to reduction ops,
e.g. reduce_sum, reduce_max, etc. However, 13863 does not
process the case of int64 support, it merely fixes the crash.

This fix adds the support for int64 axis of reduction ops.
Signed-off-by: NYong Tang <yong.tang.github@outlook.com>

* Add int64 axis support for mean, prod, sum
Signed-off-by: NYong Tang <yong.tang.github@outlook.com>

* Add int64 axis support for min and max.
Signed-off-by: NYong Tang <yong.tang.github@outlook.com>

* Add int64 axis support for reduce_all and reduce_any
Signed-off-by: NYong Tang <yong.tang.github@outlook.com>

* Add test cases for int64 axis support of reduce_any and reduce_all
Signed-off-by: NYong Tang <yong.tang.github@outlook.com>

* Improve resize_bicubic performance by reorganizing loops

This fix tries to address the issue raised in 13693 where
performance of `resize_bicubic` is not on par with opencv.

This fix rearranges the loops so that it is the same for
num_channel=40 and num_channel=3:

Pre-fix:
```
CHANNEL=40
opencv: 145.08ms
tf: 314.26ms

CHANNEL=3
opencv: 11.95ms
tf: 8.95ms
```

Post-fix:
```
CHANNEL=40
opencv: 144.25ms
tf: 214.55ms

CHANNEL=3
opencv: 11.78ms
tf: 14.07ms
```

This fix fixes 13693.
Signed-off-by: NYong Tang <yong.tang.github@outlook.com>

* Keep special handling of `num_channels=3` for `resize_bicubic`

This commit keeps special handling of `num_channels=3` for
`resize_bicubic`:
Without special handling:
```
opencv: 11.78ms
tf: 14.07ms
```
With special handling:
```
opencv: 11.74ms
tf: 9.46ms
```
Signed-off-by: NYong Tang <yong.tang.github@outlook.com>

* Expand Benchmark test for resize_bicubic
Signed-off-by: NYong Tang <yong.tang.github@outlook.com>

* Update from review feedback.
Signed-off-by: NYong Tang <yong.tang.github@outlook.com>

This fix tries to address the issue raised in 8187 where
protobuf.cmake used different version as bazel.

The reason for discrepancy was due to the fact that a customerized
protobuf was needed with Windows patch. Since the patch has been
merged in (https://github.com/google/protobuf/pull/2203),
it makes sense to update protobuf.cmake so that the same version
of cmake is used.

This fix fixes 8187.
Signed-off-by: NYong Tang <yong.tang.github@outlook.com>

* Fix doc in TF_CALL_ when defined(IS_MOBILE_PLATFORM) && !defined(__ANDROID_TYPES_FULL__)

This is a small doc fix that includes bool as part of the types
that is supported in mobile (IS_MOBILE_PLATFORM && !__ANDROID_TYPES_FULL__),
as bool is clearly invoked in the following define.
Signed-off-by: NYong Tang <yong.tang.github@outlook.com>

* Also add bool to android full version.
Signed-off-by: NYong Tang <yong.tang.github@outlook.com>

* Fix crash when `int64` axis is passed to `tf.reduce_sum`

This fix tries to fix the crash triggered by `int64` axis passed
to `tf.reduce_sum`:
```
ubuntu@ubuntu:~/tensorflow2$ (cd && python)
Python 2.7.12 (default, Nov 19 2016, 06:48:10)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tensorflow as tf
>>> v = tf.reduce_sum([1,2,3], tf.constant(0, tf.int64))
2017-10-20 15:55:06.993430: F tensorflow/core/framework/tensor.cc:601] Check failed: dtype() == expected_dtype (9 vs. 3)
ubuntu@ubuntu:~/tensorflow2$
```

The issue is caused by the fact that shape inference in `common_shape_fns.cc`
only assumes int32 without proper handling of diffent types. In `math_ops.cc`
both int32 and int64 are mentioned.

NOTE that this fix does not address the issue that int64 is not supported.
To allow int64 axis it is more than adding a template in `ReductionOp` as the type
of the axis seems to be decided by some other ways in Eigen.

This fix merely fixed the crash so that an error message will return without
exit from the python program "No OpKernel was registered to support Op 'Sum' with these attrs".

Still, I think its worth to at least allow the program to continue in case of unsupported kernel.
Signed-off-by: NYong Tang <yong.tang.github@outlook.com>

* Update implementation with a template helper function.
Signed-off-by: NYong Tang <yong.tang.github@outlook.com>

* Fix issues where int64 crops could not be passed to batch_to_space.

This fix tries to address the issue where int64 `crops` could
not be passed to `batch_to_space` even though both int32 and
int64 are specified as supported in the docs (tf.batch_to_space.__doc__)

The reason is that BatchToSpace kernel puts a constraint of int32 to crops
data types.

This fix removed the constraint so that int64 `crops` could be supported.

NOTE: Just removing the constraint should work and it is not necessary
to add specification to the kernel class template, as `SubtleMustCopyFlat`
called in the class already correctly handled both int32 and int64 cases.
Besides, other data types (e.g., float or double) will not be passed to the
kernel as they are guarded by the specification in `array_ops.cc`.
Signed-off-by: NYong Tang <yong.tang.github@outlook.com>

* Also remove int64/int32 type constraints for SpaceToBatch kernels
Signed-off-by: NYong Tang <yong.tang.github@outlook.com>

* Add test cases for int64 crops of batch_to_space and space_to_batch
Signed-off-by: NYong Tang <yong.tang.github@outlook.com>

* Fix test failures.
Signed-off-by: NYong Tang <yong.tang.github@outlook.com>

* ENH: add Relu6GradGrad

* TST: add test case

* CLN: import nn_grad

* TST: add init value

Branch 172924803

Add AdaptiveSharedBatchScheduler which processes batches at a variable rate which can be adjusted based on external feedback.  For reasonable feedback, this scheduler should deliver better latency than the SharedBatchScheduler.

PiperOrigin-RevId: 172924803

PiperOrigin-RevId: 172922818

PiperOrigin-RevId: 172922467

TFE: Raises an error when attempting to save multiple ResourceVariable objects with the same shared_name.

The only way to get multiple objects is if they're created in different Graphs/IsolateTest contexts. Previously this snuck by because of a list -> dictionary conversion without key checking.

Allows the same object to be passed multiple times (so people don't need to de-duplicate their lists).

PiperOrigin-RevId: 172921932

these classes by eliminating a large number of duplicated code.

Removing the old API is non-trivial because of the existing users
outside of tensorflow.

PiperOrigin-RevId: 172920837

PiperOrigin-RevId: 172920603

Iterating through a map in protobuf is essentially nondeterministic. This CL enables us to traverse the map in a deterministic order by sorting the keys first.

PiperOrigin-RevId: 172918084

PiperOrigin-RevId: 172915900

PiperOrigin-RevId: 172914154

PiperOrigin-RevId: 172910546

PiperOrigin-RevId: 172907182

[XLA:CPU] Do not assign parallel tasks to instructions which forward pointers (GetTupleElement and Bitcast), because the process of outlining the instruction into a parallel computation forces the pointed-to buffer to be materialized.

PiperOrigin-RevId: 172907063

PiperOrigin-RevId: 172905986

PiperOrigin-RevId: 172902682

PiperOrigin-RevId: 172902635

PiperOrigin-RevId: 172902338

PiperOrigin-RevId: 172895297

PiperOrigin-RevId: 172891551

PiperOrigin-RevId: 172891249

* improve tf.diag and tf.diag_part in CPU and GPU

* add comment

* make changes of DiagOp according to reviews

* tidy indent

* remove uesless comment prefix

* add shard function for DiagOp

* add benchmark for diag_op_test in core/kernel

* change symbol order in BUILD file

* remove empty line for Sanity Checks

* add some comments and fix benchmark throughput ratio for DiagOp

wget expects parameters before the URL on OSX (tested on
version 1.16 and 1.19)

It would fail trying to use -P as a URL

Resolving -p... failed: nodename nor servname provided, or not known.
wget: unable to resolve host address ‘-p’

PiperOrigin-RevId: 172839124

* Add `int64` out_idx` support for `listdiff`/`list_diff`/`setdiff1d`

This fix tries to add `int64` `out_idx` support for `listdiff`/`list_diff`/`setdiff1d`.
As was specified in docs (`tf.setdiff1d.__doc__`), it is possible to specify
`tf.int32` or `tf.int64` for the type of the output idx. However,
the `tf.int64` kernel has not been registered. As a consequence,
an error will be thrown out if `tf.int64` is used.

This fix adds `int64` out_idx` support for `listdiff`/`list_diff`/`setdiff1d`
Signed-off-by: NYong Tang <yong.tang.github@outlook.com>

* Add template for signature matching of ListDiff kernel.
Signed-off-by: NYong Tang <yong.tang.github@outlook.com>

* Add test cases for `int64` out_idx support for `tf.listdiff`/`setdiff1d`
Signed-off-by: NYong Tang <yong.tang.github@outlook.com>

* Add test case for int32 (missed in the last commit)
Signed-off-by: NYong Tang <yong.tang.github@outlook.com>