aboutsummaryrefslogtreecommitdiffhomepage
path: root/tensorflow/compiler/xla/service/bfloat16_propagation.cc
Commit message (Collapse)AuthorAge
* [XLA] Migrate from gtl::FlatSet to absl::flat_hash_setGravatar Benjamin Kramer2018-10-01
| | | | PiperOrigin-RevId: 215324035
* Clean-up a TODO following a previous change via b/69266521Gravatar A. Unique TensorFlower2018-09-12
| | | | PiperOrigin-RevId: 212701024
* [XLA] Rename all (Mutable)ArraySlice to absl::Span.Gravatar Tim Shen2018-08-30
| | | | PiperOrigin-RevId: 210998142
* [XLA] Fix BF16 propagation type adjustmentGravatar Yuanzhong Xu2018-07-26
| | | | | | | | | | AllUsersConsumeBF16() incorrectly used ValueTypeAfterChange() for the current value being checked, but it should be the original type. Also fusion computation should be adjusted as soon as the fusion root is adjusted. There was also redundant work for while computations. Now removed. PiperOrigin-RevId: 206216822
* [XLA] BFloat16 propagation: add de-aliasing copies before while loop inputs.Gravatar Yuanzhong Xu2018-07-09
| | | | | | | | The while loop input and output alias each other, so as long as an input is also used by other ops that could not use BF16, the propagation pass could not change such an input/ouput to BF16 even if all uses in the while loop could use BF16. Add copies for each while loop operand. This increases the chance to propagate BF16 through the while loop; if some of these copies do not help, they will remain same-shape copies and be removed at the end. This can sometimes increase HBM usage because both BF16 and F32 copies are alive, and can sometimes reduce HBM usage. PiperOrigin-RevId: 203848348
* [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
* [XLA] Use subshape pointers as map keys in BFloat16Propagation.Gravatar Yuanzhong Xu2018-06-27
| | | | | | Using simple keys is more efficient. PiperOrigin-RevId: 202377039
* Support BF16 propagation through domain instructionsGravatar A. Unique TensorFlower2018-06-18
| | | | | | | | | | | Domain instructions only there to carry some metadata so they don't effect the precision of the data so we should propagate BF16 through them. The special code needed to handle domain instructions is there as this is the only HLO what have the same tuple shaped operand and result. PiperOrigin-RevId: 200968713
* [XLA] Switch PostOrder accessors to use std::vector instead of std::list.Gravatar Benjamin Kramer2018-06-15
| | | | | | | std::list is just hilariously inefficient and the postorder list creation has been rewritten not to not depend on splicing anymore so there's no need for the list. While there remove the old unused postorder list creation code. PiperOrigin-RevId: 200743677
* Fix assumptions that a Shape must be a tuple or an array.Gravatar Mark Heffernan2018-06-13
| | | | | | | | | | | | A TOKEN primitive type was added with cl/199215963 and XLA also has an OPAQUE primitive type. However, in many places in XLA we assume either a tuple or array. This CL fixes many of those instances, but some may remain. Identified instances were discovered by searching for IsTuple or IsArray so the set of fixes is not exhaustive. Also opportunistically addressed a couple potential points of confusion in the ShapeUtil interface: (1) Rename ShapeUtil::HasZeroElements to ShapeUtil::IsZeroElementArray. The point of confusion here is that tuples can also have zero elements and HasZeroElements would check fail on tuple shapes. Method no longer check fails if the given shape is not an array. (2) ShapeUtil::IsNil now returns true only for empty tuples. Previously it also returned true for zero-element array types which was confusing because ShapeUtil::MakeNil creates an empty tuple. PiperOrigin-RevId: 200452672
* [XLA] BF16 propagation: do not change if propagation is confined inside a ↵Gravatar Yuanzhong Xu2018-05-02
| | | | | | | | | | fusion. We now use a set to track all the potential changes, and do the actual changes on the HLOs at the end. This also makes the boolean return value (whether anything is changed) correct. PiperOrigin-RevId: 195160025
* [XLA] Fix BF16 propagation bug for while condition.Gravatar Yuanzhong Xu2018-04-18
| | | | PiperOrigin-RevId: 193465140
* Using rounding when converting constants in BF16 propagation.Gravatar Yuanzhong Xu2018-03-25
| | | | PiperOrigin-RevId: 190251081
* [XLA] BF16 conversion folding for CRS; remove no-op conversions in propagation.Gravatar Yuanzhong Xu2018-03-16
| | | | | | | If CRS has tuple output, it needs special handling in conversion folding. BF16 propagation could result in BF16->BF16 conversions, which can be removed. PiperOrigin-RevId: 189380578
* [XLA] Whitelist send/recv in BF16 passes.Gravatar Yuanzhong Xu2018-03-05
| | | | PiperOrigin-RevId: 187899955
* [XLA] Support while loops and constant in HLO BF16 propagation.Gravatar Yuanzhong Xu2018-03-02
| | | | PiperOrigin-RevId: 187644155
* [XLA] Fix BF16 propagation pass to produce matching fusion root and output.Gravatar Yuanzhong Xu2018-02-23
| | | | | | | | | Previously, the propagation pass might produce different procision in the fused computation's root than the fusion itself, when the fused root doesn't define a buffer. Add explicit converts at such fusion roots. PiperOrigin-RevId: 186812368
* [XLA] HLO BF16 propagation pass.Gravatar Yuanzhong Xu2018-02-22
Using BFloat16Support provided by the backend to determine what precision is needed for each HloInstruction. If the implementation of some HLOs already reduces input precision to BF16, this pass can enable BF16 on more ops without affecting the result. PiperOrigin-RevId: 186656378
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-27 01:49:17 +0000