[Bugfix] Collect shared buffer on prelude#2471
Conversation
|
👋 Hi! Thank you for contributing to the TileLang project. Please remember to run We appreciate you taking this step! Our team will review your contribution, and we look forward to your awesome work! 🚀 |
📝 WalkthroughWalkthrough
ChangesWS Prelude Shared-Buffer Liveness Fix
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related issues
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Fixes #2443
Summary
Fixes warp-specialized kernels with a pre-loop shared-memory copy whose destination is consumed by consumer-only post-loop code.
The WS prelude classifier previously tracked local/fragment buffers but ignored shared buffers. As a result, a
T.copyon a shared buffer can remain in the common prelude. Due to warp specialization, consumer branch uses a remapped thread index, so it might be lowered to wrong thread extent and produce incorrect result.For the example listed in the issue, the IR after the
tl.PipelinePlanningis:which confirms that
T.copyfor shared buffer was left out in the prelude, and so the consumer thread gets wrong dataChanges
The fix introduces
LocalAccessCollector::CollectPrelude(...)that is specific to prelude collection that include shared buffers. It is specialized to classify prelude statement. ExistingLocalAccessCollector::Collectbehavior is unchanged. Also renamedisBranchPrivateBuffertoisTrackedBufferfor more accuracy since shared buffer is not necessarily branch private.After the fix, verified that the numeric result and IR are both correct.
Testing
Added a test the mimic the example in the original issue