[pull] master from tensorflow:master - #8802
Merged
Merged
Conversation
Bumps ubuntu from `b7f4819` to `2260313`. --- updated-dependencies: - dependency-name: ubuntu dependency-version: '24.04' dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
Update build.patch and toolchains.patch to resolve patch failures introduced by the last LLVM integrate. PiperOrigin-RevId: 974933166
…ow/tools/gcs_test/ubuntu-cd1dba6 PiperOrigin-RevId: 974961332
PiperOrigin-RevId: 974962936
…and error analysis. XLA GPU numerics monitoring requires comparing dumped LiteralProto files against golden references to detect subtle mathematical regressions. Existing tools either operate only on in-memory tensors or lack diagnostic distribution metrics. This change introduces the compare_literals tool (Phase 1): - Evaluates elementwise tolerances (abs, rel) returning pass/fail verdicts. - Computes single-pass online statistics (mean, variance, min, max) without buffer allocations. - Emits a 1D signed relative error distribution histogram with median, mean, and zero markers. - Constructs a 2D (abs, rel) error heatmap identifying Pareto frontiers and highlight target tolerances. - Automatically calculates suggested ErrorSpecs (balanced on the Pareto frontier knee point, pure absolute, pure relative) with 2x safety margins. - Supports exporting structured GitHub Flavored Markdown comparison reports via --output_markdown. PiperOrigin-RevId: 974966726
Imported from GitHub PR openxla/xla#48203 📝 Summary of Changes Query the device-specific NVLink count through NVML_FI_DEV_NVLINK_LINK_COUNT instead of relying on hardcoded constant. 🎯 Justification Two paths checked only 18/32 nvlink indices. Rubin exposes 36 NVLink ports, so both paths omitted valid links. 🚀 Kind of Contribution 🐛 Bug Fix, 🧪 Tests 🧪 Unit Tests: CudaExecutorTest.CreateDeviceDescription Copybara import of the project: -- 3a2c005e2e25b16717dc189e9d3f0422ae3e6113 by Andrei Ivanov <anivanov@nvidia.com>: [XLA:GPU] Query NVLink count from NVML Merging this change closes #48203 PiperOrigin-RevId: 974972190
This is refactoring to make methods reusable in the fission estimation code coming later PiperOrigin-RevId: 974977062
Imported from GitHub PR openxla/xla#48186 These rewrites can change NaN and infinity behavior. Preserve strict floating-point semantics by applying them only when fast math is enabled, and test both modes. 📝 Summary of Changes Gate four exponential algebraic rewrites behind `enable_fast_math`: - `exp(A) * exp(B) -> exp(A + B)` - `exp(A) / exp(B) -> exp(A - B)` - `A / exp(B) -> A * exp(-B)` - `pow(exp(A), B) -> exp(A * B)` Strict floating-point mode now preserves the original HLO, while fast-math mode retains the existing simplifications. Inspired by /pull/123991. 🎯 Justification These rewrites can change NaN and infinity behavior. This was observed in practice in #123169, where an exponential rewrite changed a NaN result to `1`. 🚀 Kind of Contribution: 🐛 Bug Fix, 🧪 Tests Updated the four existing algebraic simplifier tests to verify both strict and fast-math behavior. `//xla/hlo/transforms/simplifiers:algebraic_simplifier_test`: 1998 tests passed. No new execution test. The change is covered at the HLO pass level, and the practical failure is documented in tensorflow/ tensorflow#123169. Copybara import of the project: -- 29764815682e1e825b7b5a89a650669698fb634f by wuren <928784910@qq.com>: Gate unsafe exponential rewrites on fast math These rewrites can change NaN and infinity behavior. Preserve strict floating-point semantics by applying them only when fast math is enabled, and test both modes. Merging this change closes #48186 PiperOrigin-RevId: 974982874
PiperOrigin-RevId: 974985859
Serialize PRED elements with 8-bit storage instead of packing them at 1-bit per element with LSB masking. This allows PRED literals preserving non-zero bytes (e.g., from bitcast-convert) to round-trip through serialization and deserialization without losing upper bits. PiperOrigin-RevId: 974992146
Imported from GitHub PR openxla/xla#46604 ## Problem `ArrayMemRegion::FromZerothElementPointer` in `xla/python/ifrt_proxy/common/array_util.cc` accumulates the byte span of a strided array using an unchecked `int64_t` multiplication: ```cpp last_element_byte_offset += (stride * (shape.dims()[i] - 1)); ``` When `stride * (dims[i] - 1)` overflows `int64_t` and wraps to zero (e.g. `stride = 2^62`, `dims[i] = 5`: `2^62 × 4 = 2^64 ≡ 0`), the computed memory region size equals `byte_size` regardless of the true array span. `FromMinimalMemRegion` then compares this against the caller-supplied data size, which an IFRT proxy client also controls - so the size check passes and validation is bypassed. This affects two gRPC handlers in `IfrtBackend`: - **`MakeArrayFromHostBuffer`**: the PjRt backend is handed a small host buffer declared as a multi-element strided array and reads elements at offsets up to `(N-1) × stride` bytes beyond it (OOB read). - **`CopyToHostBuffer`**: the server allocates a `byte_size`-byte `std::string` for the output, then the PjRt backend writes `N` strided elements into it (heap buffer overflow). ## Fix Use `OverflowSafeMultiply` (already available in `xla/overflow_util.h`) before accumulating `last_element_byte_offset`, and return `InvalidArgumentError` on overflow. Add `//xla:overflow_util` to the `array_util` BUILD target. ## Changes - `xla/python/ifrt_proxy/common/array_util.cc`: replace unchecked multiplication with `OverflowSafeMultiply`; add `#include "xla/overflow_util.h"` - `xla/python/ifrt_proxy/common/BUILD`: add `//xla:overflow_util` dep Copybara import of the project: -- 767ad4ff23c76f5c98d24d60be61823e6ea4c1b4 by destro4evr-rgb <destro4evr@proton.me>: Fix integer overflow in IFRT proxy byte-strides size check stride * (shape.dims()[i] - 1) in FromZerothElementPointer was an unchecked int64_t multiplication. With stride=2^62 and dims[i]=5 the product wraps to zero, making the computed memory region size equal to byte_size regardless of the true array span. FromMinimalMemRegion then compares this against the caller-supplied data size which an IFRT proxy client also controls, so the size check passes and validation is bypassed. This allows an IFRT proxy client to trigger an OOB read via MakeArrayFromHostBuffer (PjRt backend reads elements at offsets up to (N-1)*stride bytes beyond a byte_size-byte buffer) and a heap buffer overflow via CopyToHostBuffer (server allocates byte_size bytes then PjRt writes N strided elements into it). Fix: use OverflowSafeMultiply before accumulating last_element_byte_offset and return InvalidArgumentError on overflow. Add //xla:overflow_util to the array_util BUILD target. -- 17c3961eaca239c9ece44d7f73eb0dff32422909 by destro4evr-rgb <destro4evr@proton.me>: Add unit tests for byte-stride overflow rejection in ArrayMemRegion Cover the case where stride * (dim - 1) wraps to zero on overflow, which would otherwise bypass the size check in FromMinimalMemRegion. -- 1d9d9c48ff35155f50eb670c920f5e7a3ea185dc by destro4evr-rgb <destro4evr@proton.me>: Address review nit: use dim[i] in overflow error message for clarity -- 4fcd4bf21bd59f6a415f28f0fe64e8c4438a1c9e by destro4evr-rgb <destro4evr@proton.me>: Fix error message: dim -> dim[i] only in formula part per review suggestion -- 1501c18038b6359e2f32f09980f6f32d09ade373 by destro4evr-rgb <destro4evr@proton.me>: address review: use __builtin_mul_overflow instead of OverflowSafeMultiply -- 9fb74f2c39dd0a1a05c3456ca411f0379fd305f7 by destro4evr-rgb <destro4evr@proton.me>: address review: remove overflow_util BUILD dependency Merging this change closes #46604 PiperOrigin-RevId: 975008318
Imported from GitHub PR openxla/xla#48240 📝 Summary of Changes Two fixes necessary to fix PowerPC builds. 🎯 Justification Without those, building on PowerPC doesn't work. 🚀 Kind of Contribution 🐛 Bug Fix Copybara import of the project: -- 141e584924fbf2d4dc57fbb2664dc10c30e76cc5 by Katarzyna Kubaj <kgotlinux@gmail.com>: Include <cstdint> in builtin_fp16.h The last branch of the XlaF16ABIType selection falls back to uint16_t, but the header includes nothing, so uint16_t is undeclared: xla/backends/cpu/codegen/builtin_fp16.h:32:23: error: unknown type name 'uint16_t' followed by a cascade of "unknown type name 'XlaF16ABIType'" wherever the alias is used. The fallback is unreachable on x86_64 and on AArch64, which is why this has gone unnoticed; it is taken on any target whose compiler does not provide _Float16, such as clang on powerpc64. -- 5f4811d70aca4733c6fc9d8b9045ebf9b0a11e75 by Katarzyna Kubaj <kgotlinux@gmail.com>: Require _Float16 support for the vectorised CPU intrinsics vector_ops.h and eigen_unary.cc are guarded on ext_vector_type and __builtin_vectorelements, but the body of vector_ops.h then declares typedef _Float16 Vec8h __attribute__((vector_size(16))); clang provides both of those attributes on powerpc64 while rejecting _Float16 there: xla/codegen/intrinsic/cpp/vector_ops.h:31:9: error: _Float16 is not supported on this target so the guard admits targets that cannot compile the code. Test __FLT16_MANT_DIG__ as well, which is the same predicate builtin_fp16.h already uses to decide whether _Float16 is available. Both files then compile to empty translation units on such targets, which is the behaviour the existing guard was written to provide. x86_64 and AArch64 are unaffected: clang defines __FLT16_MANT_DIG__ there (on x86 whenever SSE2 is available, i.e. always on x86_64). Merging this change closes #48240 PiperOrigin-RevId: 975008760
PiperOrigin-RevId: 975009593
`OneDnnThreadpool` checks for `ENABLE_ONEDNN_ASYNC` macro. This is defined in `tsl_copts` and is missing from the current `copts`. PiperOrigin-RevId: 975014094
PiperOrigin-RevId: 975017508
…ctorizeLoad trunc-user walk Imported from GitHub PR openxla/xla#48202 This PR fixes exponential re-exploration in the recursive walk used during the transitive search over arith.trunci users that narrow to a sub-byte type. Because the walk did not track visited operations, reconverging use graphs could cause compile-time hangs, even though the generated result was unchanged. testcase fixed: random_lax_test.py::DistributionsTest.testDirichlet0 random_lax_test.py::DistributionsTest.testDirichlet1 Copybara import of the project: -- 3efdc9351c894156759a2a36fcd7a22c34972305 by abhinav srivastava <abhinav2.srivastava@intel.com>: Prevent compile-time hangs in VectorizeLoad trunc-user walk -- 2ce582918457d7cbabebdfafabc7a5974e4926c9 by abhinav srivastava <abhinav2.srivastava@intel.com>: Added braces to single-statement ifs in the lambda Merging this change closes #48202 PiperOrigin-RevId: 975019469
…eclaration. PiperOrigin-RevId: 975020955
Removes the deprecated createExpandHloTuplesPass wrapper taking entryFunctionName from mhlo/transforms/passes.h. PiperOrigin-RevId: 975025831
Imported from GitHub PR openxla/xla#47656 📝 Summary of Changes This PR adds F64 data-type support for matmul for oneAPI 🚀 Kind of Contribution ✨ New Feature Copybara import of the project: -- e788342caf3961a175c7cd213f6ee6e64f659624 by Kanvi Khanna <kanvi.khanna@intel.com>: Add F64 support for matmul -- 5a196e8306f6843a51c61c538b6d10bd2cf61146 by Kanvi Khanna <kanvi.khanna@intel.com>: update comment -- f8be87dbe282c22d9608ec20c9f677cf521a50f3 by Kanvi Khanna <kanvi.khanna@intel.com>: Address review comments and format -- 1afeb93d6cbc0627755a675f9bc5411ec33c1251 by Kanvi Khanna <kanvi.khanna@intel.com>: use absl_assign_or_return Merging this change closes #47656 PiperOrigin-RevId: 975030465
- Explicitly define rules_cc 0.2.20 in workspace3.bzl. - Call compatibility_proxy_repo() in WORKSPACE and workspace1.bzl to define @cc_compatibility_proxy in WORKSPACE mode. - Bump rules_cc to 0.2.20 in MODULE.bazel. - Bump bazel_skylib to 1.9.0 in workspace3.bzl and MODULE.bazel to support the 'scope' attribute on bool_flag used by rules_cc 0.2.20. - In third_party/googleapis/build_rules.bzl.oss, load cc_proto_library from protobuf instead of rules_cc defs.bzl, avoiding errors from the removal of cc_proto_library in rules_cc >= 0.2.18. PiperOrigin-RevId: 975045752
PiperOrigin-RevId: 975045823
`Comparison::Order` was introduced to distinguish data type classification from mathematical ordering, but the migration was never completed across HloProto and HLO text format. This change adds `comparison_order` to `HloInstructionProto`, supports parsing `order=` on `compare` HLO instructions, and fixes `Comparison` constructor initialization so `type_` and `order_` stay synchronized during the migration. PiperOrigin-RevId: 975052031
Migrates LowerHloToLoops in kernel_creator.cc to construct TileLoopsPassOptions instead of calling the legacy pass wrapper. PiperOrigin-RevId: 975064328
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.
14 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 : )