aboutsummaryrefslogtreecommitdiffhomepage
path: root/tensorflow/compiler/xla/service/hlo_dataflow_analysis.cc
diff options
context:
space:
mode:
authorGravatar A. Unique TensorFlower <gardener@tensorflow.org>2018-07-03 14:07:02 -0700
committerGravatar TensorFlower Gardener <gardener@tensorflow.org>2018-07-03 14:12:38 -0700
commitbdd84aa59d3bdedc42647711e401229f489c7d25 (patch)
tree695399ae3fed6bc65177f38493dee35f5f74e116 /tensorflow/compiler/xla/service/hlo_dataflow_analysis.cc
parenta6471888cc9dfe9c18d121149bc0516a3f423fbb (diff)
[TF:XLA] Split select HLO into array- and tuple-select.
Array select and tuple-select already are handled separately in all backends and HLO passes: Array select is an elementwise operation. The shapes of the to operands have the same dimensions. Tuple select does not define its own output, but instead forwards the true- or false- operand based on a scalar predicate operand. This CL reflects this by adding a new kTupleSelect HLO. The XLA builder interface stays the same and dispatches based on the operand shapes. No change in the operation semantics. This CL just splits the existing select operation into two opcodes and preserves the existing semantics. HLO cost analysis is fixed to handle the two ops appropriately. PiperOrigin-RevId: 203180342
Diffstat (limited to 'tensorflow/compiler/xla/service/hlo_dataflow_analysis.cc')
-rw-r--r--tensorflow/compiler/xla/service/hlo_dataflow_analysis.cc20
1 files changed, 10 insertions, 10 deletions
diff --git a/tensorflow/compiler/xla/service/hlo_dataflow_analysis.cc b/tensorflow/compiler/xla/service/hlo_dataflow_analysis.cc
index ebed2cfc59..de1a32d8bd 100644
--- a/tensorflow/compiler/xla/service/hlo_dataflow_analysis.cc
+++ b/tensorflow/compiler/xla/service/hlo_dataflow_analysis.cc
@@ -577,17 +577,17 @@ bool HloDataflowAnalysis::UpdateParameterValueSet(HloInstruction* parameter) {
}
}
-bool HloDataflowAnalysis::UpdateSelectValueSet(HloInstruction* select) {
- CHECK_EQ(select->opcode(), HloOpcode::kSelect);
- // A phi value is not defined at a kSelect instruction because kSelect does
- // not create a new value. Rather it forwards a value from its operands. This
- // contrasts with kWhile instruction (which does define a phi value) which has
- // in-place update semantics.
+bool HloDataflowAnalysis::UpdateTupleSelectValueSet(HloInstruction* select) {
+ CHECK_EQ(select->opcode(), HloOpcode::kTupleSelect);
+ // A phi value is not defined at a kTupleSelect instruction because
+ // kTupleSelect does not create a new value. Rather it forwards a value from
+ // its operands. This contrasts with kWhile instruction (which does define a
+ // phi value) which has in-place update semantics.
bool changed = false;
for (auto& pair : GetInstructionValueSet(select)) {
const ShapeIndex& index = pair.first;
if (index.empty()) {
- // kSelect copies (not forwards) the top-level value.
+ // kTupleSelect copies (not forwards) the top-level value.
continue;
}
HloValueSet& value_set = pair.second;
@@ -649,8 +649,8 @@ bool HloDataflowAnalysis::UpdateInstructionValueSet(
return UpdateCopyValueSet(instruction);
case HloOpcode::kGetTupleElement:
return UpdateGetTupleElementValueSet(instruction);
- case HloOpcode::kSelect:
- return UpdateSelectValueSet(instruction);
+ case HloOpcode::kTupleSelect:
+ return UpdateTupleSelectValueSet(instruction);
case HloOpcode::kTuple:
return UpdateTupleValueSet(instruction);
case HloOpcode::kParameter:
@@ -849,7 +849,7 @@ Status HloDataflowAnalysis::InitializeInstructionValueSets() {
}
break;
case HloOpcode::kCopy:
- case HloOpcode::kSelect:
+ case HloOpcode::kTupleSelect:
case HloOpcode::kTuple:
// These instructions only define their top-level values. Any other
// values flow from their operands.