Repository navigation
[pull] master from tensorflow:master - #8855
Merged
Merged
Conversation
NumPy raises AxisError when sum/prod/mean/amax/amin/std/var receive an out-of-bounds axis. The shared _reduce helper forwarded the axis to the backend kernel unvalidated, producing a confusing runtime failure. Add static bounds validation for sequence axes with statically known rank, consistent with the cumsum/compress/moveaxis validation pattern.
…bounds # Conflicts: # tensorflow/python/ops/numpy_ops/tests/np_test.py
Fixes a data race seen in free threading builds. PiperOrigin-RevId: 989154130
Something is broken at head. PiperOrigin-RevId: 989195429
…line Clean up dead, redundant, and duplicate passes in `AddNewXtileToVectorPasses` and `AddNewVectorToLLVMPasses`: - Remove `RegisterOptimizationPasses` before `LowerXTileEntryPass` (it ran `LoopInvariantCodeMotion`, `SymbolDCE` before `xtile.entry_func` was lowered). - Remove `ConvertElementwise0DTensorToScalarPass`, because the VectorizeXtile.cc handles it anyway. - Move `StablehloTargetIndependentOptimizationPass` it was a no-op pass after the vectorization. - Remove duplicate `LowerToLLVMPass` invocation in `AddNewVectorToLLVMPasses`. PiperOrigin-RevId: 989201049
PiperOrigin-RevId: 989215525
…nspose ops PiperOrigin-RevId: 989230950
Currently, we remove the constraints from the indexing maps before constructing ApplyIndexingOps. Because of that we miss some of the arithmetic simplifications, because with the contraints the result range might be smaller and that would in turn enable some simplification/folding. I think a proper fix would be to allow constraints in apply_indexing. However, that could affect the compile time severely. I will experiment with that in a follow up. Even if we allow constraints, it makes sense to cache the ranges to save on compute a bit. PiperOrigin-RevId: 989262341
… coalescing and WriteN. PiperOrigin-RevId: 989374464
…-integer-pow PiperOrigin-RevId: 989438759
Imported from GitHub PR openxla/xla#49586 📝 Summary of Changes - Add `//xla/stream_executor/rocm:rocm_platform_test`, the ROCm twin of `cuda_platform_test` / `sycl_platform_test`. - Cover `PlatformWithName("ROCM")` and `FindExisting` after `ExecutorForDevice`. 🎯 Justification Add more unit test coverage on ROCm platform. 🚀 Kind of Contribution 🧪 Tests Copybara import of the project: -- e712cca80234d5417a06533eee3fff9fa9fdd633 by linchen1 <lin.chen1@amd.com>: Add rocm_platform_test. Signed-off-by: linchen1 <lin.chen1@amd.com> Merging this change closes #49586 PiperOrigin-RevId: 989479036
Previously, `ScatterDeterminismExpander` only checked for out-of-bounds scatter indices when updates were non-scalar. For scalar updates with multi-dimensional scatter indices, `SortIndicesAndUpdates` flattened the indices via a dot product with the operand strides without validating each component. Out-of-bounds coordinates in one dimension (e.g., `(0, 4)` or `(1, -4)` on a `[2, 4]` operand) could wrap into adjacent rows and overwrite valid elements instead of being dropped. Additionally, for non-scalar updates with implicit dimensions, `out_of_bound_tensor` was padded with `0`s for implicit dimensions via `AddImplicitDimensionsToIndices`. When `ExpandIndices` added non-zero window offsets along an implicit dimension, the flattened out-of-bounds index could collide with valid in-bounds indices. Validate multi-dimensional scatter indices and mask out-of-bounds rows with `out_of_bound_tensor` in the scalar-update path before sorting, and recreate `out_of_bound_tensor` via `CreateBoundTensor` using the full index-to-operand dimension mapping when implicit dimensions are added. Fixes #49380 PiperOrigin-RevId: 989480847
PiperOrigin-RevId: 989481023
The autotuner shares the cuDNN handle by multiple threads potentially causing race conditions. From the documentation (https://docs.nvidia.com/deeplearning/cudnn/latest/developer/misc.html#thread-safety): "The cuDNN library is thread-safe. Its functions can be called from multiple host threads, so long as the threads do not share the same cuDNN handle simultaneously." PiperOrigin-RevId: 989481298
CuDNN graphs do not support the following pattern ``` const = bf16[] constant(6) conv = f32[] convert(const) ``` PiperOrigin-RevId: 989496996
…Context This allows later changes to evaluate tiling candidates concurrently, each in its own context. This is essential because mlir contexts in GpuCompiler are not thread-safe. PiperOrigin-RevId: 989503240
…umulator PiperOrigin-RevId: 989508467
PiperOrigin-RevId: 989509701
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
12 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )