| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
No support in any of the backends, and not yet exposed through XlaBuilder.
PiperOrigin-RevId: 216465753
|
|
|
|
|
|
| |
Add a variant of CustomCall which specifies arbitrary layout constraints on the operands and result. The existing non-layout-constrained CustomCall is changed to have no layout preference and can now be assigned arbitrary layouts by layout assignment.
PiperOrigin-RevId: 216249615
|
|
|
|
| |
PiperOrigin-RevId: 215794086
|
|
|
|
|
|
| |
one function.
PiperOrigin-RevId: 215501702
|
|
|
|
|
|
| |
Also stop truncating operands in the canonical format.
PiperOrigin-RevId: 215466465
|
|
|
|
|
|
|
|
|
|
| |
Many of the HLO parser tests verify that an text form of an HLO module preserves all information when running through ToString then parsing. It makes sense to also use these tests to exercise proto serialization/deserialization. This is done by adding additional instantiations of the parameterized parsing tests. This caught several bugs which are fixed in this CL:
(1) Domain instructions were not being serialized properly.
(2) Host send/recv instructions did not preserve the is_host_transfer bit.
(3) Sparse literals could not be serialized or deserialized.
PiperOrigin-RevId: 215445200
|
|
|
|
|
|
| |
The intent of this field is to enable more information to be encoded in the custom call and passed through to the backend.
PiperOrigin-RevId: 214800539
|
|
|
|
|
|
|
|
| |
Add HloSchedule as a field on HloModule. This will enable scheduling to be a normal HLO pass and enable some passes such as copy insertion to more easily use tighter instruction live ranges based on the schedule. This change required adding HloSchedule to the "hlo" library because of circular dependencies.
Nothing except for tests actually sets the schedule at the moment, but follow up cls will add a scheduling pass which will do so.
PiperOrigin-RevId: 211815293
|
|
|
|
| |
PiperOrigin-RevId: 211762464
|
|
|
|
|
|
|
|
| |
If the feature_group_count is 1, don't bother showing it as it is not very
informative and a very common scenario. This is consistent with the
HloCustomCall's feature_group_count attribute.
PiperOrigin-RevId: 211560372
|
|
|
|
|
|
|
| |
- Test operand_precision in HLO parser
- Test that HloInstruction::Clone() preserves operand_precision.
PiperOrigin-RevId: 211030698
|
|
|
|
| |
PiperOrigin-RevId: 211023297
|
|
|
|
|
|
|
| |
This extends the Iota HLO to have a broadcast field. This allows for higher
rank kIota operations.
PiperOrigin-RevId: 210600435
|
|
|
|
| |
PiperOrigin-RevId: 210576458
|
|
|
|
|
|
| |
Also move 'using' statements into namespaces.
PiperOrigin-RevId: 210055083
|
|
|
|
| |
PiperOrigin-RevId: 210049592
|
|
|
|
|
|
|
| |
Unfortunately this has to be one big patch, because e.g. absl::StrCat
doesn't accept a TF StringPiece, but as soon as we switch to
absl::string_view, we have to switch away from all of the TF functions.
PiperOrigin-RevId: 209957896
|
|
|
|
|
|
|
|
| |
- Remove unused field 'cross_replica_sum_barrier' for Alltoall.
- Update cost analysis. There's no computation in Alltoall.
- Cleanup stale TODOs.
PiperOrigin-RevId: 209814190
|
|
|
|
| |
PiperOrigin-RevId: 209780185
|
|
|
|
|
|
| |
Converts "free variable" operands into parameters.
PiperOrigin-RevId: 209691261
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL renames the various inputs to the Gather HLO to be more mnemonic by
making it more obviously a batch dynamic-slice. The replacements I made are:
s/elided_window_dims/collapsed_slice_dims/g
s/window_bounds/slice_sizes/g
s/gather_dims_to_operand_dims/start_index_map/g
s/gather_indices/start_indices/g
s/output_window_dims/offset_dims/g
PiperOrigin-RevId: 209051067
|
|
|
|
|
|
|
| |
This is a first step towards supporting grouped convolutions, which are a
generalization of depthwise convolution.
PiperOrigin-RevId: 208950311
|
|
|
|
|
|
| |
Allow '/*...*/' and '//' comments to appear anywhere in HLO text, including multi-line comments. Previously only '/*...*/' comments were only allowed and only in certain locations in a serialized Literal.
PiperOrigin-RevId: 208519204
|
|
|
|
| |
PiperOrigin-RevId: 207971529
|
|
|
|
| |
PiperOrigin-RevId: 207349071
|
|
|
|
|
|
| |
This defines the semantics, and adds parser and shape inference support. Since support is not plumbed through the rest of the compiler here, multi-output reduce is still rejected by the HLO verifier, and is not exposed through XlaBuilder.
PiperOrigin-RevId: 207148035
|
|
|
|
| |
PiperOrigin-RevId: 206959456
|
|
|
|
|
|
| |
XLA:GPU uses a custom-call with window/dim_labels to represent a call to
cudnn.
PiperOrigin-RevId: 206339219
|
|
|
|
| |
PiperOrigin-RevId: 205447892
|
|
|
|
|
|
|
|
| |
Adds a bit on kSend/kReceive instructions and their Done variants indicated whether the operations communicates with the host or another device (the default). Host send/recv operations are single-sided without a complementary recv/send instruction in another module.
Host send/recv operations are exposed in the XLA builder API as SendToHost and RecvFromHost.
PiperOrigin-RevId: 205008138
|
|
|
|
| |
PiperOrigin-RevId: 203997296
|
|
|
|
|
|
| |
This is a follow up to cl/202069017 which added tokens as operands to Send and Recv.
PiperOrigin-RevId: 203145403
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This is only currently implemented in the evaluator backend, and even that implementation is partial - the key and value type must match.
PiperOrigin-RevId: 202673122
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
HloModuleConfig.
PiperOrigin-RevId: 201284741
|
|
|
|
|
|
| |
HloAllReduceInstruction can't subclass HloSendRecvInstruction because channel_id was optional in all reduce. So add 'all_reduce_id' instead.
PiperOrigin-RevId: 200653920
|
|
|
|
| |
PiperOrigin-RevId: 200275384
|
|
|
|
|
|
|
|
|
|
| |
buffer.
- Previously, we say we cannot reuse operand buffer for a loop fusion node if any of the fusion's inputs is a broadcast or reshape. That's too conservative since in theory we can still reuse the operand's buffer if all the users of that particular operand are elementwise. This CL implements that.
- Also fixed a bug in previous code where a dynamic update fusion node that ends with convert (added for bf16) is not caught by the if condition currectly.
PiperOrigin-RevId: 199731488
|
|
|
|
|
|
| |
the interface to be able to describe the common AllReduce semantic.
PiperOrigin-RevId: 199376926
|
|
|
|
| |
PiperOrigin-RevId: 199208527
|
|
Now that we're using the parser inside of xla/service, it's awkward for
it to live inside of xla/tools, because everything else in there is a
standalone tool. We've already had one person be confused by this.
PiperOrigin-RevId: 198935921
|