| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
Previosuly we emitted xla::Add what isn't supported by some XLA backend
on PRED types.
PiperOrigin-RevId: 216497939
|
|
|
|
| |
PiperOrigin-RevId: 215917470
|
|
|
|
| |
PiperOrigin-RevId: 215819072
|
|
|
|
|
|
|
|
| |
* Add kernels for TensorListReserve. EmptyTensorList, TensorListElementShape, TensorListPushBack, TensorlistPopBack;
* Treat list type pretty much identical to Stack in the bridge for now;
* Support variant output by treating variant like a uint8 and leaving the interpretation up to the XlaExpression (variant type does not support tensor_data());
PiperOrigin-RevId: 215809335
|
|
|
|
| |
PiperOrigin-RevId: 215795518
|
|
|
|
| |
PiperOrigin-RevId: 215724324
|
|
|
|
|
|
|
|
| |
Also clear "_kernel" attributes of nodes if they are set to "host".
This is not meaningful when processing the graph for XLA, and it
would prevent finding the registered XLA kernel.
PiperOrigin-RevId: 215722216
|
|
|
|
|
|
|
|
| |
stateless_random_normal.
Fixes #22611
PiperOrigin-RevId: 215385610
|
|
|
|
| |
PiperOrigin-RevId: 215324035
|
|
|
|
| |
PiperOrigin-RevId: 214824023
|
|
|
|
| |
PiperOrigin-RevId: 214711381
|
|
|
|
| |
PiperOrigin-RevId: 214675055
|
|
|
|
|
|
| |
data_format attr.
PiperOrigin-RevId: 214608039
|
|
|
|
| |
PiperOrigin-RevId: 214076068
|
|
|
|
|
|
| |
This was blocked by an LLVM bug, which was fixed in r342542.
PiperOrigin-RevId: 213953743
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL splits the functionality in XlaLaunch into two separate operations:
- XlaCompile, responsible for compiling a TF function into a LocalExecutable
- XlaRun, responsible for executing a LocalExecutable created by XlaCompile
This CL is a stepping stone towards implementing lazy compilation for TF/XLA.
The XlaCompile op is spec'ed to return a boolean indicating whether the
compilation was successful. Right now that boolean is always set to true by
XlaCompile and its value is otherwise ignored, but in the future it will be used
to indicate whether the TF function was compiled or not, and thus whether we
should execute XlaRun or just directly call the TF function.
XlaLaunch still exists, and will be created by create_xla_launch_op.cc. In the
future we may consider removing it altogether. build_xla_launch_ops.cc, now
renamed to build_xla_ops.cc, creates a XlaCompile/XlaRun pair instead of
XlaLaunch.
This CL is organized as follows:
- jit/ops/xla_ops.cc gets two new XLA-specific operations, XlaCompile and
XlaRun, described above. XlaRun redundantly takes the must-be-constant
inputs to the TensorFlow cluster to keep the implementation simple (simple in
the sense of similar to XlaLaunch), but I will remove this in a subsequent
cleanup CL.
- jit/kernels/xla_ops.cc implements XlaCompile and XlaRun in a fairly
straightforward manner. XlaCompile compiles the TF function, puts it in a
process-global storage, XlaExecutableClosureStore, and produces a int64 key.
XlaRun uses the key to read out the LocalExecutable and execute it. I'm not
sure if XlaExecutableClosureStore should be a resource like
XlaCompilationCache; I did not immediately see any reason to make it so.
- There are changes to the various _device files to register XlaCompile and
XlaRun for the XLA_* devices.
- Finally, I had to fix some tests that were expecting XlaLaunch in the
execution timeline.
PiperOrigin-RevId: 213895405
|
|
|
|
|
|
|
|
|
|
|
|
| |
These have the same behavior as unquantized types so we can just pass them
through to XLA (which converts them to unquantized types). They're supposed to
be used with special ops, none of which are currently implemented by XLA.
Casting (without quantization) and basic math works fine though.
These do not have a corresponding numpy type, so only tests using TF types will
see them.
PiperOrigin-RevId: 213781650
|
|
|
|
|
|
| |
The bug is still there and makes this test flakily fail with fp16.
PiperOrigin-RevId: 213669453
|
|
|
|
|
|
|
| |
This is used by the random number generator. Same algorithm as for float, just with more
precision. fp16 is upcasted to fp32 and then processed with the float algorithm.
PiperOrigin-RevId: 213648736
|
|
|
|
|
|
|
|
| |
This has been fixed a while ago. Even though TF allows ClipByValue for complex
types it's not implemented anywhere (and it doesn't make sense for complex
numbers) so blacklist complex types.
PiperOrigin-RevId: 213615429
|
|
|
|
| |
PiperOrigin-RevId: 213611371
|
|
|
|
|
|
|
|
|
|
| |
Being able to run CPU tests remotely while running GPU tests locally required
multiple changes:
1. Unify how we tag GPU tests in TF; we now always use tf_cuda_tests_tags().
2. Tag tests using tf_cuda_tests_tags() with 'local' and 'gpu'; this makes
them not run on non-gpu builds and always runs them locally.
PiperOrigin-RevId: 213601626
|
|
|
|
|
|
|
|
|
|
| |
The test changes are awkward. None of these are XLA bugs, it's just that the op
definitions in tensorflow are really inconsistent. I tried to infer whether the
limitation is on signed types, index types or just arbitrary. In the latter
case just int8/uint8 is blacklisted, we should probably lift that requirement
at some point.
PiperOrigin-RevId: 213243906
|
|
|
|
| |
PiperOrigin-RevId: 212972521
|
|
|
|
|
|
| |
Make the test large to prevent occasional timeouts on CPU. This should normally complete in well under a minute.
PiperOrigin-RevId: 212953337
|
|
|
|
| |
PiperOrigin-RevId: 212873250
|
|
|
|
|
|
| |
I need this in a subsequent CL where I'll rewrite the Slice TF op to DynamicSlice in some cases.
PiperOrigin-RevId: 212715067
|
|
|
|
| |
PiperOrigin-RevId: 212643986
|
|
|
|
| |
PiperOrigin-RevId: 212600364
|
|
|
|
| |
PiperOrigin-RevId: 212595533
|
|
|
|
|
|
|
|
| |
self.test_session() has been deprecated in 9962eb5e84b15e309410071b06c2ed2d6148ed44 as its name confuses readers of the test. Moving to cached_session() instead which is more explicit about:
* the fact that the session may be reused.
* the session is not closed even when doing a "with self.test_session()" statement.
PiperOrigin-RevId: 212336417
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The CL is organized as follows:
- The main change is in jit/partially_decluster_pass.
- tf2xla/const_analysis now takes an "edge_filter" to facilitate use by
jit/partially_decluster_pass.
- tests/dense_layer_test.py was using the execution of ListDiff as what I
assume is a sanity check to see that the XLA cluster ran. With this CL the
ListDiff op gets declustered so we now check for "MatMult" for the sanity
check.
- Some tests were dropping TF_XLA_FLAGS; fixed them to not do so.
PiperOrigin-RevId: 212071118
|
|
|
|
| |
PiperOrigin-RevId: 211948271
|
|
|
|
|
|
| |
GPU would fail due to having too many parameters to fit in memory because Concat's signature is variadic and can have an unlimited number of inputs.
PiperOrigin-RevId: 211942734
|
|
|
|
|
|
| |
The "Proto" suffix adds little clarity but makes a long type name even longer.
PiperOrigin-RevId: 211693871
|
|
|
|
|
|
|
|
| |
consistently
StringPiece is an alias for absl::string_view, InlinedVector is aliased to absl::InlinedVector. StrCat is compatible, so swapping it out is safe.
PiperOrigin-RevId: 211691840
|
|
|
|
| |
PiperOrigin-RevId: 211134202
|
|
|
|
|
|
|
|
|
|
|
|
| |
original change.
This CL fixes additional two CI tests that broke due to the changed bfloat16 behavior.
==================================================
Automated rollback of commit 37b2b0eb613b6c3c66b96374851cfd95050346a0
PiperOrigin-RevId: 211031073
|
|
|
|
| |
PiperOrigin-RevId: 210998142
|
|
|
|
|
|
|
|
| |
There are several API migrations happening:
* ArraySlice's sub-slice constructor => .subspan
* MutableArraySlice's container pointer constructor => absl::MakeSpan
PiperOrigin-RevId: 210946124
|
|
|
|
| |
PiperOrigin-RevId: 210870412
|
|
|
|
|
|
| |
should not end up in the accumulator.
PiperOrigin-RevId: 210648271
|
|
|
|
| |
PiperOrigin-RevId: 210613802
|
|
|
|
| |
PiperOrigin-RevId: 210512603
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are a couple of reasons to do this:
- resource handle are regular tensors part of a public API that
can potentially be returned from a function.
- When tfe.defun is executed under GradientTape, it generates a
function returning resource handles in certain cases.
This CL adds support for returning resource handles from an XLA
compiled function. These resource handles must have been passed as
arguments to the function. In other words, we don't yet support
returning resources created inside the function. tfe.defun never
makes functions that create resources.
PiperOrigin-RevId: 210442856
|
|
|
|
|
|
| |
Documentation previously disallowed slices where start and limit indices were the same, but it was allowed by the implementation. Updated the documentation to support the implementation.
PiperOrigin-RevId: 210379434
|
|
|
|
| |
PiperOrigin-RevId: 210129265
|
|
|
|
| |
PiperOrigin-RevId: 210116745
|
|
|
|
| |
PiperOrigin-RevId: 209997425
|
|
|
|
| |
PiperOrigin-RevId: 209988299
|