aboutsummaryrefslogtreecommitdiffhomepage
path: root/tensorflow/compiler/xla/service/hlo_dataflow_analysis_test.cc
Commit message (Collapse)AuthorAge
* [XLA] Add documentation and HLO-level support for multi-value sort.Gravatar Michael Kuperstein2018-10-09
| | | | | | No support in any of the backends, and not yet exposed through XlaBuilder. PiperOrigin-RevId: 216465753
* [XLA] Allow scatter to share the operand buffer with the outputGravatar Benjamin Kramer2018-10-09
| | | | | | This avoids a copy. PiperOrigin-RevId: 216437329
* Rollforward of cl/211656888 after fixing failing unit test.Gravatar Mark Heffernan2018-09-05
| | | | | | | | | | | *** Original change description *** Add HloSchedule class representing a sequential order of an HloModule. Currently we represent a sequential schedule of a module using a SequentialHloOrdering::HloModuleSequence which is a type alias of a bare map from HloComputation* to std::vector<HloInstruction*>. This CL replaces this with a proper class which results in better encap... *** PiperOrigin-RevId: 211726890
* [XLA] Rename PrecisionConfigProto to PrecisionConfigGravatar David Majnemer2018-09-05
| | | | | | The "Proto" suffix adds little clarity but makes a long type name even longer. PiperOrigin-RevId: 211693871
* BEGIN_PUBLICGravatar Mark Heffernan2018-09-05
| | | | | | Automated rollback of commit 7fa693209fe238478739b3982f652a7e35be91f3 PiperOrigin-RevId: 211681957
* Add HloSchedule class representing a sequential order of an HloModule.Gravatar Mark Heffernan2018-09-05
| | | | | | | | Currently we represent a sequential schedule of a module using a SequentialHloOrdering::HloModuleSequence which is a type alias of a bare map from HloComputation* to std::vector<HloInstruction*>. This CL replaces this with a proper class which results in better encapsulation of code which deals with schedules and better enforcement of invariants. This CL also fixes a corner-case bug in dataflow analysis, where values of instructions which are live out of the computation erroneously did not interfere with the values of instructions scheduled after the root instruction. PiperOrigin-RevId: 211656888
* [XLA] Make kConvolution, kDot HLO attributes mandatoryGravatar David Majnemer2018-09-04
| | | | | | | | HLO transformations would forget to propagate the feature depth attribute. Making these attributes mandatory, while slightly less convenient for tests, makes HLO transformations more robust. PiperOrigin-RevId: 211490160
* [TF:XLA] Make the two functions for computing HLO buffer interference ↵Gravatar A. Unique TensorFlower2018-08-23
| | | | | | | | | | | | | | consistent. Consider only real uses of fusion parameters when computing buffer interference using HloDataflowAnalysis. This is a step in unifying our HLO dataflow framework to a single source of truth and improves HloOrdering::LiveRangeStrictlyBefore to match the behavior of BufferLiveness::live_range_strictly_before (which uses TuplePointsToAnalysis) PiperOrigin-RevId: 209966644
* [XLA] Clean up clang tidy readability warnings in compiler/xlaGravatar Benjamin Kramer2018-08-06
| | | | | | | | | | | | | | | | * lambda capture 'builder' is not used * using decl 'Printf' is unused * lambda capture 'this' is not used (17 times) * lambda capture 'buffer_liveness' is not used * lambda capture 'computation' is not used * lambda capture 'operand_to_generator' is not used * lambda capture 'M' is not used * using decl 'InvalidParameterArgument' is unused * lambda capture 'sum' is not used * lambda capture 's' is not used * lambda capture 'epsilon' is not used PiperOrigin-RevId: 207542895
* Allow Sort to share the buffer with the operand if it is the only user.Gravatar Adrian Kuegel2018-07-31
| | | | | | | | | | The BitonicSort algorithm works in-place, so we can make use of that. On GPU, so far we copied the operand to the output and then performed the algorithm in-place. Now, we may not need to do this anymore if we see that the buffer is shared. Also, we now only need device-to-device copies in case the buffer is not shared, because constants are now also assigned a buffer. PiperOrigin-RevId: 206745686
* Add WithToken variants to Send/Recv/Infeed/Outfeed ops in XLA builder.Gravatar Mark Heffernan2018-07-09
| | | | | | | | 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
* [TF:XLA] Split literal_util into {literal, literal_util}.Gravatar Kay Zhu2018-07-03
| | | | | | | | | 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
* [TF:XLA] Split select HLO into array- and tuple-select.Gravatar A. Unique TensorFlower2018-07-03
| | | | | | | | | | | | 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
* Change Send, SendDone, Recv and RecvDone to produce tokens.Gravatar Mark Heffernan2018-07-03
| | | | | | This is a follow up to cl/202069017 which added tokens as operands to Send and Recv. PiperOrigin-RevId: 203145403
* Change Send and Recv HLOs to take a token operand.Gravatar Mark Heffernan2018-07-02
| | | | | | 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
* Add backend specific lambda to decide whether a fusion instruction can share ↵Gravatar A. Unique TensorFlower2018-06-21
| | | | | | buffer with its operand. PiperOrigin-RevId: 201615582
* Mark input/output fusion and dynamic update slice as elementwise.Gravatar Yunxing Dai2018-06-21
| | | | PiperOrigin-RevId: 201580442
* Enable multioutput fusion opearnd buffer reuse.Gravatar Yunxing Dai2018-06-21
| | | | | | | | - Enable multioutput fusion opearnd buffer reuse. - Fix a bug in heap simulator where a buffer can be reused twice. - Add unittest. PiperOrigin-RevId: 201567720
* [DataFlowAnalysis] Be less conservative on loop fusion nodes when reusing ↵Gravatar Yunxing Dai2018-06-07
| | | | | | | | | | 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
* Move DoesNotUseOperandBuffer and CanShareOperandBufferWithUser fromGravatar Jeremy Lau2018-05-16
| | | | | | liveness_util to methods on TuplePointsToAnalysis and HloDataflowAnalysis. PiperOrigin-RevId: 196903216
* Fix the HLO alias analysis and copy insertion to cope with the new ↵Gravatar A. Unique TensorFlower2018-03-15
| | | | | | kConditional instruction. PiperOrigin-RevId: 189245979
* [XLA] Pass the module to HloDataflowAnalysis by const reference.Gravatar Michael Kuperstein2018-02-16
| | | | PiperOrigin-RevId: 186072673
* [XLA] Implement Conditional in XLA service, client ComputationBuilder, and ↵Gravatar A. Unique TensorFlower2017-12-07
| | | | | | CPU backend. PiperOrigin-RevId: 178322445
* Fix a few issues with HloValue and dataflow analysis identified when ↵Gravatar Mark Heffernan2017-11-14
| | | | | | | | | | | | debugging the causes for the rollback of the new copy insertion (cl/174423881): (1) Mark values for deletion during dataflow propagation and delete later, rather than delete immediately. It was possible for a value to be deleted (a phi is optimized away), and still have references to it in the value sets. (2) Make call/while and root instructions explicit uses of the values which reach them. This subsumes the need for the HloValue::live_out_of_computation_ property which was buggy (which computation is it live-out of?). (3) Delete unused methods HloValue::RecomputeUses and HloValue::RemovePosition. PiperOrigin-RevId: 175765613
* Change for asynchronous Send and Recv by splitting Send into {Send, SendDone}Gravatar HyoukJoong Lee2017-11-10
| | | | | | | and Recv into {Recv, RecvDone}. See operation_semantics.md for the updated semantics. PiperOrigin-RevId: 175216012
* Add liveness_util functions which use dataflow analysis. Also make the ↵Gravatar Mark Heffernan2017-09-18
| | | | | | analysis argument (TuplePointsToAnalysis or HloDataflowAnalysis) non-optional as all callers were passing in the analysis. PiperOrigin-RevId: 169200824
* Use xla/tests:xla_internal_test_main for all tests under tf/compiler/xlaGravatar Mark Heffernan2017-09-12
| | | | | | | and remove any main() definitions in tests. This enables use of flags in all tests. PiperOrigin-RevId: 168424796
* Add flag parsing to more tests in xla/service specifically those which buildGravatar Mark Heffernan2017-09-12
| | | | | | | | HLO graphs. This enables, for example, dumping of the graphs with --xla_generate_hlo_graph. Also remove some superfluous tensorflow test_main dependencies. PiperOrigin-RevId: 168406746
* Rollback update-ability of dataflow and alias analysis added in cl/164923041 ↵Gravatar Mark Heffernan2017-09-01
| | | | | | and cl/64778750. It did not scale as intended to large graphs when used in copy insertion. This change also includes some simplification and performance improvements to dataflow and alias analysis. Also add some value-ordering tests to HloOrderingTest using dataflow analysis to generate values. PiperOrigin-RevId: 167283460
* Make HloDataFlowAnalysis updatable after transforming the HLO graph.Gravatar Mark Heffernan2017-08-09
| | | | | | | | | | | | | | | | | | | | Updating is possible if operands/uses or computation roots change in the graph. Updating is not possible if instructions are deleted or if new instructions are added. Specific changes: * Add verification methods for asserting invariants and checking the analysis after updating. * Always add phi values at while instructions. Previously these were added only if the phi had different inputs. The advantage of using phi's unconditionally is that the set of values is fixed for a module. Updates due to changing operands/uses in the graph do not create new values. * Store values in a vector rather than a map. With unconditional phi values, the number of HloValues is fixed so the values can be held in a vector with stable references to elements. PiperOrigin-RevId: 164778750
* Change HloBuffer, HloBufferSet and HloValueSet to hold pointers rather than ids.Gravatar A. Unique TensorFlower2017-07-12
| | | | | | | | | This makes it easier to implement logic like returning the size of an HloBuffer, which requires knowing the underlying HloValues. No functional changes; only a change of representation. PiperOrigin-RevId: 161737042
* Rename HloLocation to HloPosition, to avoid ambiguity with MemoryLocation.Gravatar A. Unique TensorFlower2017-07-12
| | | | PiperOrigin-RevId: 161716528
* [XLA] Add live range interference querying to dataflow analysis.Gravatar Mark Heffernan2017-06-19
| | | | | | | | | | | | Add method MayInterfere to HloDataflowAnalysis which returns whether the live ranges of two values interfere. This will replace buffer_liveness.cc. The cl includes a few related changes: (1) HloOrdering: Apply an order to the condition and body computations. Specifically, for the purposes of HLO ordering the condition is ordered before the body. This ensures that the live ranges of values in the condition do not interfere with the live ranges in the body. (2) Add a Dominates method to CallGraph for determining whether a computation dominates another in the call graph. (3) Tightened the definition of "use" in the dataflow analysis. Now an instruction which passes through a value without reading it is no longer considered a use of the value. This new definition is reflected in the HloUse objects returned by HloValue::uses(). PiperOrigin-RevId: 159509724
* Remove class xla::LiteralUtil. NFC (mind-numbingly so).Gravatar A. Unique TensorFlower2017-06-19
| | | | | | This patch removes class xla::LiteralUtil and rewrites every call to use class xla::Literal instead. PiperOrigin-RevId: 159446373
* [XLA] Add HLO alias analysis.Gravatar Mark Heffernan2017-06-09
| | | | | | | | Add HloAliasAnalysis which identifies aliasing of buffers in the HLO graph. This analysis is module-scoped and will eventually replace the computation-scoped TuplePointsToAnalysis. Currently the analysis is unused, but later CLs will incrementally replace TuplePointsToAnalysis with HloAliasAnalysis (or potentially HloDataflowAnalysis). This CL also includes a small change to HloDataflowAnalysis. When ssa_form is true, only while instructions (which update inplace) define phi values. Previously, subcomputations called from multiple kCall instructions would also define phi values. Effectively this is an inconsequential change because we always flatten the callgraph eliminating multiple callsites for the same subcomputation. PiperOrigin-RevId: 158537805
* [XLA] Add HloLocation to dataflow analysis.Gravatar Mark Heffernan2017-06-07
| | | | | | | | Add an HloLocation abstraction to dataflow analysis which indicates where (in the output of what instruction and at which index) an HloValue may appear. Previously only uses were stored with an HLO value where a use is an edge in the HLO graph (instruction, operand number and ShapeIndex). Also, change the handling of tuple-shaped kSelect instructions when ssa_form is true. Previously a phi value would be created. With this change the the value set instead contains the union of it's inputs identical to the ssa_form=false case. PiperOrigin-RevId: 158276598
* [XLA] Add module-scoped HLO dataflow analysis.Gravatar Mark Heffernan2017-06-05
This is the first step to replacing TuplePointsToAnalysis with a global, module-scoped analysis. This dataflow analysis identifies all values and their defs and uses in the XLA graph. The analysis is currently unused. Follow up CLs will add buffer alias analysis using this dataflow analysis, and incrementally switch the transformation passes (for example, CopyInsertion) to use these new module-scoped analyses. PiperOrigin-RevId: 158067910
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-09 05:50:25 +0000