skip reduction when comparing alloc domains in transpose scheduler

[liqiangxl]

reduction domain is ignored in transpose scheduler, it usually comes from reduction from a segmented fusion, e.g. test ReductionIterDomainOnInputsIssue1659

[github-actions]

Description

• Filter out reduction domains before comparing allocation domains in transpose scheduler

• Prevent incorrect scheduling decisions when reduction domains are present

• Update test case to expect PointWise scheduler instead of Transpose for reduction scenarios

• Fix issue where transpose scheduler incorrectly handles fusion with reduction iter domains

Changes walkthrough

	Relevant files
Bug fix	domain_map.cpp Filter reduction domains in transpose scheduler comparison csrc/scheduler/tools/domain_map.cpp Add filtering logic to exclude reduction domains before comparison Use std::views::filter with is_not_reduction lambda Apply filtering to both ref1_loop and ref2_loop before std::ranges::equal Update any_bcast checks to use filtered domains +9/-3
Tests	test_transpose.cpp Update test to expect PointWise scheduler for reductions  tests/cpp/test_transpose.cpp Update test expectation from Transpose to PointWise scheduler Fix test case for reduction iter domain scenario Ensure test validates correct scheduling behavior +1/-1

PR Reviewer Guide

Here are some key observations to aid the review process:

🧪 PR contains tests

⚡ Recommended focus areas for review

Filter Logic Correctness The new filtering logic correctly excludes reduction domains from allocation domain comparison. The lambda is_not_reduction and the use of C++20 ranges appears correct, but verify that all reduction domains should indeed be excluded in this context and that the filtering doesn't inadvertently remove domains that should be considered for scheduler selection. auto is_not_reduction = [](IterDomain* id) { return !id->isReduction(); }; auto ref1_filtered = ref1_loop | std::views::filter(is_not_reduction); auto ref2_filtered = ref2_loop | std::views::filter(is_not_reduction); Test Expectation Validation The test change from expecting Transpose scheduler to PointWise scheduler should be validated to ensure this reflects the correct behavior. Confirm that the fix properly handles the reduction domains and that PointWise is indeed the appropriate scheduler for this case. heuristic1 == SchedulerType::PointWise,

[liqiangxl]

!test

[greptile-apps]

Greptile Overview

Greptile Summary

Fixed transpose scheduler selection logic to correctly handle reduction domains from segmented fusions. The hasAtLeastTwoValidGroups function now filters out reduction domains before comparing allocation domains, preventing the transpose scheduler from incorrectly identifying valid groups when reduction domains are present.

Key changes:

• Added filtering logic using std::views::filter to exclude reduction domains when comparing allocation domains
• Updated test expectation to verify PointWise scheduler is now correctly selected instead of Transpose scheduler for the affected case

Confidence Score: 4/5

• This PR is safe to merge with minimal risk
• The fix is targeted and well-motivated - it addresses a specific issue where reduction domains from segmented fusions were causing incorrect scheduler selection. The use of C++20 ranges is consistent with the codebase, and the test update confirms the expected behavior. Score of 4 (not 5) due to the subtle nature of scheduler selection logic.
• No files require special attention

Important Files Changed

Filename	Overview
csrc/scheduler/tools/domain_map.cpp	Filters out reduction domains before comparing allocation domains in hasAtLeastTwoValidGroups, preventing incorrect transpose scheduler selection when reduction domains are present from segmented fusions
tests/cpp/test_transpose.cpp	Updates test expectation from Transpose to PointWise scheduler for second segment in ReductionIterDomainOnInputsIssue1659, reflecting the corrected scheduler selection behavior

[greptile-apps]

_{2 files reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}

[naoyam]

We already have a constant for this.

[naoyam]

LGTM