Guard empty sharding group in findCommonSharding

[EylonKrause]

Problem

Running a propagation pass standalone on a module with a non-contiguous sdy.sharding_group id crashes — findCommonSharding calls groupMembers.front() on an empty ValueRange. For example, sdy_opt -sdy-basic-propagate on a group whose id starts at 1 (no group 0):

sdy.mesh @mesh = <["x"=2]>
func.func @f(%a: tensor<8xf32> {sdy.sharding = #sdy.sharding<@mesh, [{"x"}]>},
             %b: tensor<8xf32>) -> tensor<8xf32> {
  sdy.sharding_group %a group_id=1 : tensor<8xf32>
  sdy.sharding_group %b group_id=1 : tensor<8xf32>
  return %b : tensor<8xf32>
}

Root cause

ShardingGroupMap sizes its shardingGroupToValues vector by group-id value (resize(max(getGroupId() + 1, size))), so a non-contiguous id leaves empty gap slots. syncGroupMemberShardings then enumerates every slot — including the gaps — and calls findCommonSharding(groupId, {}). findCommonSharding only special-cases the size-1 case, so an empty range falls through to groupMembers.front(), which is undefined behavior.

group_id is a plain I64Attr with no verifier constraining it to a contiguous 0..N range, so a group starting at id 1 is valid input. The full -sdy-propagation-pipeline canonicalizes ids via ShardingGroupImportPass first, but the propagation passes are independently registered and run directly on sharding_group ops (as in the propagation tests).

Fix

Return an empty result for an empty group; the caller already skips groups with no common sharding (if (!sharding) continue;).

Test

non_contiguous_sharding_group_id in sharding_group_propagation.mlir: a group with id 1 and no id 0 now propagates without crashing.

---

Disclosure: this contribution was authored with an AI coding assistant (Claude) and reviewed before submission.