| Commit message (Collapse) | Author | Age |
|
|
|
| |
PiperOrigin-RevId: 216452447
|
|
|
|
| |
PiperOrigin-RevId: 216392908
|
|
|
|
| |
PiperOrigin-RevId: 216386450
|
|
|
|
|
|
|
| |
If the graph contains not constant array with strings it fails because the
array's size can't be estimated.
PiperOrigin-RevId: 216356162
|
|
|
|
|
|
|
| |
Use the ArgDef::type field when available for propagating
the output types from a given unsupported operator.
PiperOrigin-RevId: 216257741
|
|
|
|
|
|
| |
must be on axis 0, and can only be on 1 or 2-d inputs.
PiperOrigin-RevId: 216226776
|
|
|
|
| |
PiperOrigin-RevId: 215957535
|
|
|
|
| |
PiperOrigin-RevId: 215928419
|
|
|
|
| |
PiperOrigin-RevId: 215768310
|
|
|
|
| |
PiperOrigin-RevId: 215658384
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
turning into a constant is a
discardable array. If it's not discardable, it means that the user wants this array to keep existing
in a way that is observable to them, i.e. not as weights.
Typical example: a Fill op outputs an array that is passed as a RNN state array (non-discardable).
It seems that so far we have been relying on accidental ordering of graph transformations for such state
arrays not to be accidentally turned into constants. Instead, the desired graph transformation here is
RemoveUnusedOp noticing that such a Fill can be discarded since its output is a RNN state array.
So I don't have a test for this, but this seems to be tightening existing behavior, and should be good
to have as long as it does not regress anything.
PiperOrigin-RevId: 215500760
|
|
|
|
| |
PiperOrigin-RevId: 215487633
|
|
|
|
|
|
|
| |
unintended effect of causing the second line not to run at all depending
on the result from the first line.
PiperOrigin-RevId: 215466006
|
|
|
|
|
|
|
|
| |
are equal to either the min or the max value, so that they are trivially
exactly quantized. This case does not normally occur for true learned weights,
which is what this warning is intended for.
PiperOrigin-RevId: 215463096
|
|
|
|
| |
PiperOrigin-RevId: 215440829
|
|
|
|
|
|
| |
produced/consumed by any op.
PiperOrigin-RevId: 215402308
|
|
|
|
| |
PiperOrigin-RevId: 214835588
|
|
|
|
|
|
|
|
| |
This change reduce the size of //tensorflow/tools/pip_package:simple_console_windows's zip file from 1000027677 bytes to 47690474 bytes for a CPU build. For GPU build, it will avoid going over 4GB when multiple CUDA compatibility are specified.
To fix #22390
PiperOrigin-RevId: 214764423
|
|
|
|
| |
PiperOrigin-RevId: 214710175
|
|
|
|
| |
PiperOrigin-RevId: 214705311
|
|
|
|
| |
PiperOrigin-RevId: 214674717
|
|
|
|
|
|
|
| |
The conversion process fails for graphs that use tf.boolean_mask(..., axis=0) --
this op calls tf.concat with an empty array as the first argument.
PiperOrigin-RevId: 214451470
|
|
|
|
| |
PiperOrigin-RevId: 214309210
|
|
|
|
| |
PiperOrigin-RevId: 213917946
|
|
|
|
| |
PiperOrigin-RevId: 213885561
|
|
|
|
| |
PiperOrigin-RevId: 213729750
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Before inserting a new Transpose node, check if there already is one that
may be reused. In practice, there are two cases: either the array being
transposed is a constant (by far the most common case) or it's not.
* If it is constant, then this doesn't really make a difference:
ResolveConstantTranspose runs anyway, eliminating these Transpose nodes
and also mootifying this change as it leaves no Transpose node to be
reused. So in that case, constant-array-deduping is really the only
thing that prevents duplication of data.
* If it is not constant, that's where this new logic really helps, as
the resulting Transpose nodes are here to stay in the final graph,
and this avoids inserting more than are needed.
2. transpose_a is not supported. However, rather than CHECK-fail, it's more
useful to have this graph transformation bail with a log message. The
resulting 'unresolved' MatMul node could still be handled in some way
at the TFLite level, or we could end up having support for MatMul per se.
PiperOrigin-RevId: 213678294
|
|
|
|
|
|
| |
The main issue is we were keeping the input array, updating it in place and discarding the output array. That was a problem when the input array had multiple consumer ops. Now we're keeping the output array instead, which is the correct thing to do. However, in order to minimize disruption, we keep using the input array's name whenever possible, by means of some array renamings.
PiperOrigin-RevId: 213678219
|
|
|
|
|
|
|
| |
If this causes trouble (makes graph visualizations harder to read, etc)
then consider increasing the default value of dedupe_array_min_size_bytes.
PiperOrigin-RevId: 213656796
|
|
|
|
| |
PiperOrigin-RevId: 213227615
|
|
|
|
| |
PiperOrigin-RevId: 213017532
|
|
|
|
|
|
|
| |
The original CL was rolled back due to op registration conflicts in the pip.
Resolve the issue by only including core:ops in the toco binary itself, not in intermediate libraries.
PiperOrigin-RevId: 212902838
|
|
|
|
| |
PiperOrigin-RevId: 212890622
|
|
|
|
| |
PiperOrigin-RevId: 212884951
|
|
|
|
| |
PiperOrigin-RevId: 212651704
|
|
|
|
| |
PiperOrigin-RevId: 212577288
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Change Variant Decode to accept VariantTensorData (non-ref).
This should allow some optimization in the future.
In the meantime it means removing the variant.h include from tensor.h, since
variant_encode_decode.h now relies on tensor.h and variant.h now relies on that.
It also means we found a bunch of places where tensor.proto.h, variant.h, and
mutex.h were being imported through tensor.h (along with a bunch of other crap);
so now we directly import them in order to compile.
2. Move Variant registry to use TypeIndex instead of a TypeName string; this should
speed up registry lookups.
PiperOrigin-RevId: 212478896
|
|\
| |
| |
| | |
PiperOrigin-RevId: 212346420
|
| |
| |
| |
| | |
PiperOrigin-RevId: 211874785
|
| |
| |
| |
| | |
PiperOrigin-RevId: 211711493
|
| |
| |
| |
| | |
PiperOrigin-RevId: 211621189
|
| |
| |
| |
| | |
PiperOrigin-RevId: 211562900
|
| |
| |
| |
| | |
PiperOrigin-RevId: 211175130
|
| |
| |
| |
| | |
PiperOrigin-RevId: 211159438
|
| |
| |
| |
| | |
PiperOrigin-RevId: 211124183
|
| |
| |
| |
| | |
PiperOrigin-RevId: 211092680
|
| |
| |
| |
| | |
PiperOrigin-RevId: 211020126
|
| |
| |
| |
| | |
PiperOrigin-RevId: 211011100
|
| |
| |
| |
| | |
PiperOrigin-RevId: 211010293
|
| |
| |
| |
| | |
PiperOrigin-RevId: 210995878
|