Skip to content

Handle duplicate allocation labels during replay - #53

Draft
daxmawal wants to merge 1 commit into
mainfrom
fix/replay-duplicate-labels
Draft

Handle duplicate allocation labels during replay#53
daxmawal wants to merge 1 commit into
mainfrom
fix/replay-duplicate-labels

Conversation

@daxmawal

@daxmawal daxmawal commented Sep 9, 2026

Copy link
Copy Markdown
Member

Kokkos allocations can share the same label. Previously, replay allocations and reference outputs were indexed by label, so one allocation could hide another and make output comparison unreliable. This change preserves each allocation separately and matches inputs with their reference outputs using the captured allocation pointer and memory space. The new get_allocations API exposes these pairs through ReplayAllocation descriptors. New compare_views overloads accept a descriptor and support explicit dimensions or a flat view whose size is inferred from the recorded byte count.

Label-only lookups report an error when the label is ambiguous.
Tests cover duplicate labels, reordered references, empty allocations, and comparison size validation.

P.S. I encountered this issue in a Dyablo Kokkos kernel where multiple views shared the same label.

Match input allocations and reference outputs by captured allocation pointer
and memory space. Expose allocation descriptors for unambiguous comparisons,
including flat views whose extent is inferred from the recorded byte count.

Reject ambiguous label-only lookups and cover duplicate labels, reordered
references, empty allocations, and comparison size validation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant