| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
Same for WrapUnique.
PiperOrigin-RevId: 209531124
|
| |
|
|
|
|
|
|
| |
In HLO side-effecting ops now take and produce a token-shaped value used for ordering. This CL exposes the tokens in the XLA builder interface by adding builder variants suffixed with "WithToken". These variants have an extra token-shaped operand and produce a token, sometimes as a element in the tuple-shaped output of the op.
Also, at the HLO level, add new method CreateToken for creating an instruction which produces token-shaped value out of thin air using an AfterAll instruction. This is explicitly broken out from CreateAfterAll to facilitate remove of zero-operand AfterAll instructions (b/110532604).
PiperOrigin-RevId: 203834271
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Send and Recv HLOs now have an additional required operand which must be token-shaped. XLA client interface for these operations is unchanged and will be updated in follow up CLs.
PiperOrigin-RevId: 202993121
|
| |
|
|
|
|
|
|
| |
Long term I think we want to require kAfterAll to take at least one token as operand so it cannot generate a token out of thin air, so kGenerateToken is no longer an appropriate name. Instead, a primordial token would be supplied some how in the entry computation, perhaps as a parameter, and then threaded to any side-effecting ops.
NFC.
PiperOrigin-RevId: 202079040
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tokens are primitive types which can be threaded between side-effecting operations to order them. This CL changes infeed and outfeed to take a token as an operands and produce a token as one of its outputs. The most disruptive aspect of this change is that infeed now produces a two-element tuple containing the data value and a token. This means the shape of infed data no longer is the same as the shape of the infeed instruction, and a get-tuple-element operation must be called on the infeed instructions output to get its data.
Related changes/notes:
- The computation builder interface is unchanged. The infeed builder constructs an infeed instruction followed by a GTE instruction to extract the data value. Client and computation builder interface changes will be in follow up cls.
- Tokens can now be the root of the entry computation. Previously tokens could not be passed into or out of the entry computation. But now that outfeed produces a token, this constraint meant that outfeed could not be a root which is awkward. In the future we'd like to pass in tokens as well, perhaps as the only way of generating the initial token to thread through side-effecting ops.
- Infeed and outfeed still have a form which does not take a token to minimize the size of this CL. In the future this form will be removed. However, most HLO tests using infeed/outfeed are changed to accept a token in this cl.
PiperOrigin-RevId: 202041518
|
| |
|
|
|
|
| |
and moved the condition to the hlo_dce pass.
PiperOrigin-RevId: 177215395
|
| |
|
|
|
|
|
| |
We get a dead computation when e.g. we delete a reduction or remove a
while loop.
PiperOrigin-RevId: 172135511
|
| |
|
|
|
|
|
|
| |
Currently it returns a view of unique_ptr<HloInstruction>s. But the
fact that these are unique_ptrs is an implementation detail, and it's
ugly to leak it everywhere.
PiperOrigin-RevId: 170445375
|
| |
|
|
|
|
|
| |
and remove any main() definitions in tests. This enables use of flags
in all tests.
PiperOrigin-RevId: 168424796
|
| |
|
|
|
|
|
| |
removable from a computation. This is to prevent DCE from removing a
while instruction that includes a send/recv instruction.
PiperOrigin-RevId: 164722478
|
| |
|
|
|
|
| |
This patch removes class xla::LiteralUtil and rewrites every call to use class
xla::Literal instead.
PiperOrigin-RevId: 159446373
|
| |
|
|
| |
PiperOrigin-RevId: 158522608
|
| |
|
|
|
|
|
| |
Removing instructions with control dependencies may result in a violation
of the ordering constraint which the control dependency is intended to
enforce.
Change: 154190963
|
|
|
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
|
Justin Lebar
Mark Heffernan
Kay Zhu
HyoukJoong Lee
A. Unique TensorFlower
Eli Bendersky
Peter Hawkins