| Commit message (Collapse) | Author | Age |
|
|
|
| |
PiperOrigin-RevId: 193301997
|
|
|
|
|
|
|
|
|
|
| |
In an ideal world this won't make a difference since the compiler should be
disciplined about not leaking host-level optimization artifacts into generated
code. However, I think this provides some defense-in-depth in preventing
non-obvious denormal behavior on the host side from messing up floating point
constants etc. we want to embed into generated code.
PiperOrigin-RevId: 186061140
|
|
|
|
|
|
|
|
|
|
| |
In an ideal world this won't make a difference since the compiler should be
disciplined about not leaking host-level optimization artifacts into generated
code. However, I think this provides some defense-in-depth in preventing
fast-math optimization on the host side from messing up floating point constants
etc. we want to embed into generated code.
PiperOrigin-RevId: 185941549
|
|
|
|
|
|
|
|
| |
In a later change, the GPU backend will use this allocator to reserve
scratch memory when trying out different convolution algorithms during
compilation.
PiperOrigin-RevId: 183469579
|
|
|
|
|
|
| |
without optimizations.
PiperOrigin-RevId: 176158846
|
|
For CPU and GPU this is a simple wrapper around the single-module Compile method
since the CPU and GPU backends do not perform cross-module optimizations and
analyses.
PiperOrigin-RevId: 175631791
|