| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
arguments to the constructor to remove some boilerplate.
PiperOrigin-RevId: 210855509
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
For now, this verifier checks some noncontroversial invariants, like:
- Fusion operands and fusion computation parameters must have matching layouts.
- Same for while loops, calls, kConditional.
It's a bit of a pain to add these explicit layout-sensitive and
allow-mixed-precision flags everywhere, but I think it's better than
adding default args. With default args we can easily mix up the order,
and we'd only be able to add new flags to the end of the list.
PiperOrigin-RevId: 210059349
|
| |
|
|
|
|
|
|
| |
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
|
|
|
true_computation, false_computation) to Call(predicated_computation) and
finally inlined computation.
PiperOrigin-RevId: 187376657
|
Dimitris Vardoulakis
Justin Lebar
Mark Heffernan
Kay Zhu