| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
| |
when the if then/else body of If or the While body funcs do not have stateful
ops.
The are lowered to the same XLA ops.
One use case is in the S4TF compiler: https://github.com/apple/swift/pull/18509
PiperOrigin-RevId: 207977126
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TF_AddGradients could create nodes in the graph with names that conflicted with
other nodes in the graph. This would most clearly happen if TF_AddGradients()
was called twice on the same graph, and could also happen if there were other
nodes in the graph that happened to have "gradients" as a prefix of their name.
Fix that.
The added test in c_api_test.cc would fail in the call to TF_SessionRun() with
Node 'gradients/OnesLike' is not unique
without the changes to c_api.cc and c_api_internal.h
While at it, also fixed a possible name collision bug when using the C++ API
to constructor graphs (using Scope).
Thanks @karllessard for pointing this out.
PiperOrigin-RevId: 202087996
|
|
|
|
|
|
| |
in this header because it happens to be forward-declared in one of the other .proto.h headers, but it's not actually used there and will go away.
PiperOrigin-RevId: 196217574
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This initial design of the C API is different from (and mostly higher level
than) the python API counterparts for infeed, in that the python API has
explicit graph construction APIs for generating infeed enqueue/dequeue
ops (e.g. split_inputs_and_generate_enqueue_ops() and generate_dequeue_op()),
while the C API takes an input graph and redirects all input nodes to feed the
infeed enqueue.
One requirement/restriction is that the input nodes in the TF
graph (e.g. Placeholder) must specify their tensor shapes, for infeed enqueue
and dequeue nodes to properly compile with XLA. The API for more general shape
support will be designed and implemented later.
PiperOrigin-RevId: 189693028
|
|
|
|
|
|
| |
to take a TF_DataType param.
PiperOrigin-RevId: 188570493
|
|
|
|
| |
PiperOrigin-RevId: 187532378
|
|
|
|
|
|
| |
Also refined the API comment for TF_NewSession().
PiperOrigin-RevId: 185739196
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary of changes:
1. Set MarkForCompilationPassFlags::tf_xla_cpu_global_jit default to true in
C_API unit test env when XLA-execute is intended. Together with setting session
config config.graph_options.optimizer_options.global_jit_level to > 0, this
turns on XLA for the entire graph (eligible nodes only, with _Arg and _RetVal
nodes excluded).
We decided against defaulting MarkForCompilationPassFlags::tf_xla_cpu_global_jit
to true, due to performance concerns with the single-threaded nature of the XLA
CPU backend (see
https://www.tensorflow.org/performance/xla/jit#turning_on_jit_compilation).
2. In FindCompilationCandidates() during MarkForCompilationPass, skip compiling
any '_Arg'-typed nodes. This is necessary to avoid hitting a "Invalid argument
number" error during MarkForCompilationPass.
3. Extended C API based build rules to link in XLA libraries, and added unit
test "CAPI.Session_Min_XLA_CPU".
Also added some misc improvements and debugging aids.
PiperOrigin-RevId: 185193314
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
support.
This CL adds XLA support for the following TFE_Op's:
1. A TF op such as MatMul, with full support of constant and resource params.
2. A TF_Function as TFE_Op, where the function must have no constant and
resource params. Removing this restriction requires more discussion and will be
deferred to a later time.
PiperOrigin-RevId: 184877345
|
|
|
|
|
|
| |
They don't make sense in the open source repository.
PiperOrigin-RevId: 183140889
|
|
|
|
| |
PiperOrigin-RevId: 179953488
|
|
|
|
| |
PiperOrigin-RevId: 178909147
|
|
|
|
| |
PiperOrigin-RevId: 178759398
|
|
|
|
|
|
| |
This fixes a bug where two calls to the same stateful function will erroneously be eliminated as common subexpressions. It is also a step towards pruning nodes from function bodies, which is necessary for a variety of `Dataset` optimizations.
PiperOrigin-RevId: 178675527
|
|
|
|
| |
PiperOrigin-RevId: 169245946
|
|
|
|
|
|
|
|
|
|
| |
Also, change the internal representation of TF_Function and
rename TF_GraphAddFunction to TF_GraphAddFunctionCopy to make it
clear that a copy of the function is added to the graph. Any
subsequent modifications to the function will not be reflected
in the copy added to the graph.
PiperOrigin-RevId: 169187793
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this change, we call IsValidOutputTensor() on the returned
outputs from the condition and body functions. This will return a bad
status if no output or a null output is set, or if an output has a bad
index.
This also adds unit tests for related error cases to the C and C++
unit tests. They often produce different errors because the C
implementation goes through the graph constructor.
PiperOrigin-RevId: 167925641
|
|
|
|
|
|
|
|
| |
This change adds minimal functionality. Support for FunctionOptions,
attributes, output name rewriting, function name generation, etc is
comming next.
PiperOrigin-RevId: 167091238
|
|
This change also separates shared functionality into
c_test_util.h/cc. This brings c_api_test.cc to a mere 1715 LOC
(further splits can be more easily done now too).
PiperOrigin-RevId: 162216399
|