| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Happened to observe this come up in a linear algebra workload.
PiperOrigin-RevId: 211290278
|
|
|
|
|
|
| |
dependencies as well.
PiperOrigin-RevId: 211038094
|
|
|
|
|
|
|
| |
This allows us to use e.g. cudnn's padding, instead of materializing a
kPad instruction.
PiperOrigin-RevId: 211028379
|
|
|
|
| |
PiperOrigin-RevId: 210998142
|
|
|
|
|
|
|
|
|
|
| |
We were using a broadcast of a constant instead of the kIota HLO.
To make switching to kIota practical, we need to do a few things first:
- Don't constant fold kIota.
- Don't hoist kIota from loops without good cause.
PiperOrigin-RevId: 210825834
|
|
|
|
| |
PiperOrigin-RevId: 210634966
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
This adds a field to the proto so that we may serialize it.
On TPUs, we can simulate higher precision by splitting a float32 number into several bfloat16 numbers such that their sum closely approximates the original number.
A tensor contraction operation like convolution or a dot product can be computed by forming several partial products which approximate the correct answer to a closer margin.
PiperOrigin-RevId: 209720948
|
|
|
|
| |
PiperOrigin-RevId: 209686671
|
|
|
|
|
|
| |
Same for WrapUnique.
PiperOrigin-RevId: 209531124
|
|
|
|
| |
PiperOrigin-RevId: 209502513
|
|
|
|
| |
PiperOrigin-RevId: 209248552
|
|
|
|
| |
PiperOrigin-RevId: 209247783
|
|
|
|
| |
PiperOrigin-RevId: 208746565
|
|
|
|
| |
PiperOrigin-RevId: 208092411
|
|
|
|
| |
PiperOrigin-RevId: 206782323
|
|
|
|
|
|
| |
With clamping semantics, if the shapes match, the indices are always clamped to zero.
PiperOrigin-RevId: 206013929
|
|
|
|
|
|
| |
to Accumulate(Reudce(),Reduce(),...Reduce())
PiperOrigin-RevId: 205740411
|
|
|
|
| |
PiperOrigin-RevId: 204797049
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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
|
|
|
|
| |
PiperOrigin-RevId: 202401460
|
|
|
|
| |
PiperOrigin-RevId: 202152026
|
|
|
|
| |
PiperOrigin-RevId: 201783076
|
|
|
|
| |
PiperOrigin-RevId: 201765455
|
|
|
|
|
|
|
|
|
|
|
|
| |
instruction.
Extend ReshapeIsBitcast to handle copy instructions. This allows algebraic
simplifier, for example, to replace a copy from shape f16[1,1,128,128]{3,2,1,0}
to shape f16[1,1,128,128]{1,0,3,2} to bitcast for the CPU and GPU backends.
Add a test case.
PiperOrigin-RevId: 201699400
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
PiperOrigin-RevId: 200086761
|
|
|
|
|
|
| |
Also forcing reduction order for init to be on lhs for ReduceWindow->Map pass.
PiperOrigin-RevId: 198953817
|
|
|
|
|
|
| |
simplifier reshape change is now covered by ReshapeMover.
PiperOrigin-RevId: 198802494
|
|
|
|
|
|
|
| |
These maps aren't really pulling their weight, fold them to the instruction
that they compute.
PiperOrigin-RevId: 197967117
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
batchnorm expander
Otherwise we create a lot of identical small computations. This shouldn't have
an effect except for cluttering the HLO, but turns out HloCSE doesn't look
inside of the computation of reduces, effectively never eliminating reduces
that were produced via this code path.
While there clean up some YAGNI, this only worked for F32 anyways, so just
hardcode it.
PiperOrigin-RevId: 196689316
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and prepare for enabling more efficient interfacing from Tensor to Literal to
reduce host to device latency.
More specically:
* Introducing a new LiteralBase abstract base class that contains all immutable
methods of from the old Literal class.
* Introducing a subclass LiteralSlice to replace original LiteralView class.
LiteralSlice class is read-only and does not own Shape nor any buffer through
the Pieces. Change a number of callers to use LiteralSlice directly.
* Change Literal class to explicitly own the underlying Shape as well as owning
the underlying buffer via Piece.
* Conversion from Literal to LiteralSlice is now done via an implicit
conversion constructor instead of inheritance.
* Decouple ShapeTree from Literal classes.
* Use copy-and-swap for assignment constructors.
* Other minor cleanups.
PiperOrigin-RevId: 196016576
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dot(ConstA, ConstB)
Make transformation when ConstA and ConstB are 2D, and DynamicSlice is slicing a full row, column respectively.
Handle:
dot(DynamicSlice(Index, ConstA), ConstB) => DynamicSlice(Index, dot*(ConstA, ConstB));
and
dot(ConstA, DynamicSlice(Index, ConstB)) => DynamicSlice(Index, dot*(ConstA, ConstB));
Reason to roll forward: Previous issue of getting out of memory errors when generating LLVM constants was resolved by CSE-ing constants before allocation.
PiperOrigin-RevId: 195853680
|
|
|
|
| |
PiperOrigin-RevId: 193427566
|
|
|
|
|
|
| |
All existing backends apply the init_value on the lhs, except for the evaluator. This causes problems for reductions which apply an identity function to a reduce or reduce window.
PiperOrigin-RevId: 193091323
|
|
|
|
| |
PiperOrigin-RevId: 192862841
|
|
|
|
|
|
|
| |
Implicit broadcasts can be translated to the new instruction instead of a reshape-and-broadcast.
Follow-up CLs will add support in UserComputation and the various backends.
PiperOrigin-RevId: 192180356
|
|
|
|
|
|
|
|
|
|
|
| |
ReduceWindow operations are done in higher precision to avoid accumulation
error. Convert operations can find their way between a ReduceWindow and a Pad
which can prevent a Pad from combining with a ReduceWindow.
Fix this by looking past the Convert while also checking that the Convert'd
Pad's init value is identical to the reduce-window value.
PiperOrigin-RevId: 190686175
|
|
|
|
| |
PiperOrigin-RevId: 190322644
|
|
|
|
| |
PiperOrigin-RevId: 190242291
|
|
|
|
| |
PiperOrigin-RevId: 190139303
|
|
|
|
|
|
| |
As an optimization, replace consecutive broadcast instructions with a single equivalent broadcast in algebraic simplification.
PiperOrigin-RevId: 190127730
|
|
|
|
|
|
|
| |
The rationale here is that MakeXyzHlo is less likely to be confused with
HloInstruction::CreateXyz and we already have a convention of using a "Make"
prefix for ergonomic factory functions.
PiperOrigin-RevId: 189259036
|
|
|
|
|
|
| |
I need something like this for my Gather HLO->HLO lowering pass.
PiperOrigin-RevId: 188365102
|
|
|
|
|
|
|
|
| |
of zero.
A zero sized update has no effect.
PiperOrigin-RevId: 187510099
|
|
|
|
| |
PiperOrigin-RevId: 186929931
|
|
|
|
| |
PiperOrigin-RevId: 186539902
|
|
|
|
| |
PiperOrigin-RevId: 185944719
|