Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remove CB operands from ttir.generic #2376

Merged
merged 6 commits into from
Mar 6, 2025

Conversation

vroubtsovTT
Copy link
Contributor

@vroubtsovTT vroubtsovTT commented Mar 5, 2025

Ticket

Closes #1969

Problem description

We are moving lowering of operands to CB slots to a lower section of the d2m pipeline and hence decided to remove CB operand-related arguments from ttir.generic op.

What's changed

There are two main changes, the first is a generic tablegen cleanup action and is somewhat independent of the second:

  1. a new getDpsOutputs() helper method in ttmlir/Dialect/TTIR/IR/Utils.h will auto-detect whether a concrete OP has single or variadic outputs; using it in extraClassDeclaration of selected base tablegen classes allows multiple such trivial/repeated declarations to be removed from a number of TTIROps defs.
  2. ttir.generic has lost CB operands/mapping attributes; the enqueue program rewriter in TTIRToTTMetal.cpp pass that depends on that logic has been removed for now

Checklist

  • multiple existing tests had their operand_cb_mapping attributes removed and operandSegmentSizes adjusted accordingly

Copy link
Contributor

@nsmithtt nsmithtt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! Style nit regarding headers

#include <mlir/Interfaces/ControlFlowInterfaces.h>
#include <mlir/Interfaces/DestinationStyleOpInterface.h>
#include <mlir/Interfaces/InferTypeOpInterface.h>
#include <mlir/Interfaces/SideEffectInterfaces.h>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using the chevrons here goes against our style guide (inherited from llvm).

See https://docs.tenstorrent.com/tt-mlir/coding-guidelines.html#includes

Copy link
Contributor Author

@vroubtsovTT vroubtsovTT Mar 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've always used <> for all includes that are external to the project's source tree and thus need an include path provided to the compiler. Also have done this in several prev PRs...

Changed in the last commit.

// clang-format on
template <typename Op>
mlir::MutableOperandRange getDpsOutputs(Op *op) {
return impl::getDpsOutputs<Op>::evaluate(op);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🙌

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the usual type deduction technique

#include <mlir/CAPI/IR.h>
#include <mlir/Dialect/Tensor/IR/Tensor.h>
#include <mlir/IR/AffineMap.h>
#include <mlir/IR/BuiltinAttributes.h>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in the latest commit

}
};
} // namespace

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1300 lines removed, you must have fixed at least 10 bugs in one shot.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the best c++ code is code that doesn't exist

Copy link
Contributor

@azecevicTT azecevicTT left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

#ifndef TTMLIR_DIALECT_TTIR_IR_UTILS_H
#define TTMLIR_DIALECT_TTIR_IR_UTILS_H

#include <mlir/IR/ValueRange.h>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: <> here as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed here as well


template <typename Op>
inline constexpr bool has_variadic_outputs<
Op, std::void_t<decltype(std::declval<Op>().getOutputsMutable())>> = true;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: I find convention from STL with _v and _t handy when working with templates, though this is localized so it's okay either way.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree and I started with _v but then it seemed to me that llvm sources don't use such suffixes, so I changed. I've checked again and maybe their usage is mixed. I've gone back to _v which is my personal preference as well.

static mlir::MutableOperandRange evaluate(Op *op) {
return op->getOutputsMutable();
}
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's your opinion on this vs if constexpr? I find the latter more handy for cases like this one.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if constexpr would work here as well, as well a c++20 concept (when we can use c++20).

I think some intermediate version I had needed template specialization to instantiate single/variadic branches separately. But that's not needed in the final version so I've changed to if constexpr as more compact.

@vroubtsovTT vroubtsovTT merged commit 5e99f0f into main Mar 6, 2025
33 checks passed
@vroubtsovTT vroubtsovTT deleted the vroubtsov/update_ttir.generic_for_d2m_v1 branch March 6, 2025 02:51
@vroubtsovTT vroubtsovTT changed the title remote CB operands from ttir.generic remove CB operands from ttir.generic Mar 6, 2025
vwellsTT pushed a commit that referenced this pull request Mar 6, 2025
### Ticket
Closes #1969

### Problem description
We are moving lowering of operands to CB slots to a lower section of the
d2m pipeline and hence decided to remove CB operand-related arguments
from ttir.generic op.

### What's changed
There are two main changes, the first is a generic tablegen cleanup
action and is somewhat independent of the second:

1. a new `getDpsOutputs()` helper method in
`ttmlir/Dialect/TTIR/IR/Utils.h` will auto-detect whether a concrete OP
has single or variadic outputs; using it in `extraClassDeclaration` of
selected base tablegen `class`es allows multiple such trivial/repeated
declarations to be removed from a number of TTIROps `def`s.
2. ttir.generic has lost CB operands/mapping attributes; the `enqueue
program` rewriter in `TTIRToTTMetal.cpp` pass that depends on that logic
has been removed for now

### Checklist
- [x] multiple existing tests had their operand_cb_mapping attributes
removed and `operandSegmentSizes` adjusted accordingly
odjuricicTT pushed a commit that referenced this pull request Mar 8, 2025
### Ticket
Closes #1969

### Problem description
We are moving lowering of operands to CB slots to a lower section of the
d2m pipeline and hence decided to remove CB operand-related arguments
from ttir.generic op.

### What's changed
There are two main changes, the first is a generic tablegen cleanup
action and is somewhat independent of the second:

1. a new `getDpsOutputs()` helper method in
`ttmlir/Dialect/TTIR/IR/Utils.h` will auto-detect whether a concrete OP
has single or variadic outputs; using it in `extraClassDeclaration` of
selected base tablegen `class`es allows multiple such trivial/repeated
declarations to be removed from a number of TTIROps `def`s.
2. ttir.generic has lost CB operands/mapping attributes; the `enqueue
program` rewriter in `TTIRToTTMetal.cpp` pass that depends on that logic
has been removed for now

### Checklist
- [x] multiple existing tests had their operand_cb_mapping attributes
removed and `operandSegmentSizes` adjusted accordingly
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.

Remove cbs and operand_cb_mapping from ttir generic op
3 participants