infer pipe init nosplit from split-0 users

[zhangstevenunity]

What changed

Infer implicit nosplit = true only on internal pipe init ops when any same-logical-pipe pto.tpush, pto.tpop, or pto.tfree in the module uses split = 0.

Why

The init-side nosplit setting should be derived from pipe usage semantics instead of being carried as an explicit push/pop frontend parameter.

Impact

Generated TPipe<...> init templates now append the final true or false flag based on split-0 usage on the same pipe, while frontend and internal push/pop ops continue to use only the existing split attribute.

Root cause

The previous implementation direction risked spreading nosplit onto data ops, but the intended behavior is to keep it implicit and init-scoped.

Validation

• Updated existing EmitC/FileCheck expectations for tpush/tpop pipe init templates
• Added test/basic/tpush_tpop_frontend_nosplit_a5.pto
• Did not run ptoas locally because no usable local binary/build was available in this environment

[gemini-code-assist]

Code Review

This pull request introduces a nosplit attribute to pipe initialization operations and implements inference logic within the PTOResolveReservedBuffers pass to automatically set this attribute when downstream pipe users have a split value of 0. The EmitC backend is updated to include this boolean in the TPipe template parameters. Feedback suggests refactoring the pipe user inference loop for better readability and deduplicating the logic for resolving standalone nosplit attributes using a templated helper function.

[gemini-code-assist]

The series of if statements with continue can be refactored into a more concise if-else if chain. This improves readability and is slightly more efficient as it avoids redundant checks. The continue statements are also unnecessary since the if blocks return immediately.

  for (Operation *user : pipe.getUsers()) {
    if (auto pushOp = dyn_cast<TPushOp>(user)) {
      if (pushOp.getSplit() == 0)
        return true;
    } else if (auto popOp = dyn_cast<TPopOp>(user)) {
      if (popOp.getSplit() == 0)
        return true;
    } else if (auto freeOp = dyn_cast<TFreeOp>(user)) {
      if (freeOp.getSplit() == 0)
        return true;
    }
  }
  return false;

[gemini-code-assist]

The logic inside the two moduleOp.walk calls for InitializeL2LPipeOp and InitializeL2G2LPipeOp is identical. This code duplication can be avoided by extracting the logic into a templated helper function, which would improve maintainability.

For example, you could define a helper function:

template <typename InitOpT>
void resolveStandaloneNoSplit(InitOpT initOp,
                              const std::set<Operation *> &resolvedOps,
                              OpBuilder &builder) {
  if (resolvedOps.count(initOp.getOperation())) {
    return;
  }
  if (inferNoSplitFromPipeUsers(getPipeResult(initOp))) {
    setNoSplitAttr(initOp, builder.getBoolAttr(true));
  }
}

And then call it from the walks:

moduleOp.walk([&](InitializeL2LPipeOp initOp) {
  resolveStandaloneNoSplit(initOp, groupedNoSplitResolved, builder);
});
moduleOp.walk([&](InitializeL2G2LPipeOp initOp) {
  resolveStandaloneNoSplit(initOp, groupedNoSplitResolved, builder);
});