No functional change. Rename the proto message Layout to LayoutProto, and Tile to TileProto. Define in-place replacement C++ classes named Layout and Tile with an interface which mirrors the protobuf generated code interface. Having these data structures as C++ classes enables greater flexibility in the interface, enables enforcement of invariants, and potential performance improvements.
PiperOrigin-RevId: 225121052
Unlike Printf, StrFormat does not require type-length qualifiers, e.g
%z, %ll. Nor does it require that you call c_str() to print strings.
So these are fixed up here as well.
PiperOrigin-RevId: 210435915
Currently Literal classes sits in literal_util.{h,cc} instead of literal.{h,cc}.
It also contains helper functions that are better fit to be their own separate
class/namespace. This change starts this process by moving most static factory
methods to LiteralUtil namespace.
PiperOrigin-RevId: 203217065
This CL primarily does two things:
(1) Remove the protobuf-compatibility methods (eg, mutable_f32s()) from Literal. These were added to Literal as part of the migration of Literal from a proto to a c++ class. Now that Literal is a proper class, these protobuf methods make it difficult to enforce invariants and expose too much of the class' implementation details.
(2) Make shape an immutable property of Literals, and make shape and the data members holding the Literal data coherent by construction. Previously, the shape could be set arbitrarily, and the data members such as f32_ could be arbitrarily sized irrespective of the shape of the literal.
The remainder of the CL mostly deals with the fallout. Notable other changes:
- Literal is no longer a recursive data structure. To avoid copies when passing a subliteral of a tuple-shaped Literal, a LiteralView class is added which provides a read-only view of an arbitrary subliteral.
- Tuple-shaped Literals can no longer be built up incrementally so to avoid copying Literal values during construction, the following methods with move semantics are added: Literal::MoveFrom and Literal::MoveIntoTuple. These methods transfer ownership the underlying buffers enabling, for example, a literal to be moved into an element of a tuple-shaped literal with no data copying.
- Replace the internal data structure holding the actual data from a bunch of std::vectors (eg, s32s_, f32s, etc) to a single ShapeTree<char*>. This significantly simplifies accessors and makes improved support of tuple-shaped literals much easier (eg, Literal::Get<>() can now access elements in arbitrary subliterals).
Also, Literal is made movable, but not copyable. Otherwise, it is all too easy to accidentally introduce expensive copies of Literals. Literal::Clone is added to handle the case where a copy is needed (Literal::CloneToUnique already exists).
PiperOrigin-RevId: 181014890
This renames the existing Literal message to LiteralProto and introduces a new
C++ class named Literal to replace it.
The LiteralProto is only used at RPC boundaries, or when protobuf-specific
functionality is required. The Literal class offers a 'ToProto' function to
generate a new LiteralProto message when necessary.
Currently, all the static functions in class LiteralUtil, just forward to their
counterparts in class Literal. This will change in a future CL.
Class Literal implements all the buffers as std::vectors. The only exception
is preds(), which given the std::vector<bool> representation, makes it unusable
for the semantics we require (it's not possible to get the address of the
underlying vector, for instance).
The CL adds a BoolVector class to work around that issue.
In future CLs, the std::vector representation may be changed to something more
efficient, if needed.
PiperOrigin-RevId: 157739125
XLA is a compiler-based linear algebra execution engine that targets CPUs, GPUs and custom accelerators.
XLA is still experimental; we are releasing it early to get the community involved.
Change: 143990941
