[Fix][LLVM] Preserve 64-bit AllocBuffer extents - #20141
Draft
fallenmi wants to merge 1 commit into
Draft
Conversation
LLVM code generation narrowed constant AllocBuffer extents to int32 before creating stack allocations. Preserve the signed 64-bit extent through alignment calculation and LLVM alloca emission, while avoiding overflow in the alignment helper. Add compile-only regression coverage for large extents that previously wrapped to one or four elements. Generated-by: OpenAI Codex
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
2 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.
Fixes #20125.
What changed
LLVM CPU code generation now keeps constant
AllocBufferextents as signed 64-bit values through stack allocation emission instead of narrowing them toint32_t. The temporary-allocation alignment helper accepts the same width and avoids multiplying when a large allocation cannot reduce the requested alignment, preventing overflow in that calculation.This change is intentionally limited to the CPU
CodeGenLLVMpath. The separate NVPTX and AMDGPU overrides described in the issue remain out of scope.Why
An extent of
2**32 + 1previously wrapped to one beforeCreateAlloca, producing a one-element stack allocation followed by ani64 4294967296element access in unoptimized TIR-X LLVM IR. The generated module could therefore contain an out-of-bounds access even though the original extent was valid as anint64_t.The regression test only compiles and inspects LLVM IR; it does not execute or materialize the very large allocation. It covers extents that previously wrapped to one and four elements.
Validation
tests/python/codegen/test_target_codegen_llvm.py: 380 passedgit diff --check: passedINT64_MAX - 3: exacti64allocation counts, with no allocation executedAI assistance
This Draft PR was prepared with OpenAI Codex. The patch was derived from the repository and the issue's documented failure mode; no external third-party code was copied into the change.
Generated-by: OpenAI Codex